Hello again good people! I bring you, not trials and tribulations, but more junk to test and play with! Anyway, as some of you may or may not know, I've been working for a while now on my engine project, Ascendancy. While it's nowhere near completion yet, I'm getting close now to finishing the core, that is, file functions, memory managment, task managment, utilities, etc. Just recently, I finished my file input streams (couldn't resist a little re-invention of the wheel there [grin]) and have been benchmarking them. Currently, on my machine, they are clearly faster (as much as 400%, in some cases, like when reading with a large chunk size), but I'd like to find out whether this is universal, or whether my machine is simply a highly optimal environment for these operations. That is where you all come in.. I'd like you to download the archive located here, and run the build of the Ascendancy Console within. Here's the deal. There are 4 specific commands which I'd like you (you being whoever has downloaded it, and is going to try this) to try out 5-10 times each, they are these: InputProfile 255InputProfile 1024InputProfile 2048InputProfile Once you've used them all a couple of times, use the logProfiles command, to log the timing results to the 'Time samples.log' file, where you can browse at your lesiure (sp?). Note that these commands (the InputProfile ones, not logProfiles) simply read a file (TimingTest.txt) in in chunks of 1, 255, 1024 and 2048 bytes respectively, and print it out, and the reading is timed, as well as the opening and closing of the file. The functions called in each one are as alike as I can make them, although when the Ascendancy stream is reading, it actually calls it's eof method as well as it's Valid method, whereas the standard stream is only having the eof method called. Once you've done that, I encourage you to format the results, and post em here like this, or simply post the raw log file if you can't be bothered to format it your self. Also, I encourage you to use the help command, and try out the commands therein (regrettably not a full list), seeing if you manage to break anything [smile] It all works fine over here, but as with the streams, I'd like to verify that it works well everywhere else as well, at least at this point. Note that calling the fError command and crashing out with a notifcation and a log entry is not considered 'breaking' it, as that functionality is specifically there [smile] Thanks a lot folks, and if you want to know how my implementation works, feel free to ask, the only reason I'm not posting it right now is that this post is long enough already [grin] This program has only been verified to work on Windows XP though in theory it should also work on some other windows platforms. If you have a version of Windows other then XP, please do try everything out, I'd appreciate it. As the FileInputStream calls Windows API methods directly (as well as some of my other functions) this demo, and indeed Ascendancy, is Windows only.

Noted and appreciated [smile] I find it odd however, that your times at 1 byte per read operation are significantly lower then mine with the standard file input, while your timings with Ascendancy input are about the same.. Oh, also, I forgot to mention, please say what OS you were using. I assume you were running WinXP?

Thanks man, and again, any and all are welcome and indeed encouraged to test it out [smile]

Sceptical and curious? Yep, in reality, that sums up pretty much every programmer I've seen [grin]

I don't have the codebase here right now, I'll have to try that out tomorrow morning, when I get back to my other PC.. Regarding the complexity of standard streams, yes, I know they do a huge amount of stuff in the background. And going from the info contained in your post, I am led to believe a lot of it is getting data from devices, syncing, formatting, etc. And this is precisely the sort of stuff I don't need to have going on, so I cut it out, when straight up against the windows API, created my own middle layer. Because this is a game engine, I don't need a load of extra junk in my streams. If I want keyboard input, I'll use Direct Input, or whatever other input handler I end up using (are there even any others? I haven't heard of any, to tell you the truth).

As for the usage, well, here's my setup, roughly.. First off, we have a basic InputStream class (as well as an OutputStream, haven't done any work on that or it's derived buddies yet). Now, we have a number of classes inheriting from that InputStream, such as FileInputStream, MemoryInputStream, and their compression and/or encryption reading counterparts. I'm not out to replicate the standard library's streams, with console input, output etc, I'm just making a quick and standardized (for Ascendancy) method for accessing file and memory streams, be they plain, compressed or encrypted. That way, you have a compressed flle? Just open up a Compressed File Input Stream, and read from it as you would a normal file. An encrypted stream of serialized bytes in memory? Opum an Encryption Memory Innput Stream, read from it same as with any other memory or file stream.

I'll try out turning of syncing tomorrow, and post the results, as well as updating the build if necessary.

Oh, heheh, it's 255, because I made the character buffer a 256 array, remembered that the last character has to be the NULL terminator, and then couldn't be bothered to change all the references to it's size by 1... Also, this way, it's a size that the automatic cache size (65536) doesn't devide by, for whatever it's worth, so you'll get a cache reload in the middle of a read operation, as opposed to at the end of one. Shouldn't make any real difference though.

Did you perchance try out any of the other commands? If so, did every work fine, that is, without crashing or doing something unwarranted?

Ahh, enough for tonight, I'm turning in, it's 1:00 in the morning here...

Thanks mate, I'll look into that.

[EDIT] I tried out turning off syncing with C I/O, and here are my results:

You were definitely right snk_kid, it did have quite a positive effect on the timings of the standard filestreams, but stil not enough [smile] I'll look into trying out the basic_filebuf later on.

[Edited by - SirLuthor on June 8, 2005 7:04:43 AM]