FILES in WinAPI

**JasonD** · 09-24-2003

I was in the middle of creating a test program, and when I was writing the win32 API version, I decided to look more into the CreateFile function. For the dwFlagsAndAttributes parameter, you can use:

FILE_FLAG_RANDOM_ACCESS
Indicates that the file is accessed randomly. The system can use this as a hint to optimize file caching.

FILE_FLAG_SEQUENTIAL_SCAN
Indicates that the file is to be accessed sequentially from beginning to end. The system can use this as a hint to optimize file caching. If an application moves the file pointer for random access, optimum caching may not occur; however, correct operation is still guaranteed.
Specifying this flag can increase performance for applications that read large files using sequential access. Performance gains can be even more noticeable for applications that read large files mostly sequentially, but occasionally skip over small ranges of bytes.

It looks like the two methods that I was going to use for my test program to emulate real-world behaviour each have specific settings within CreateFile to optimize the caching... I did not finish my program, I had to leave my office right as I found out this information. I just thought I would write now, and let you know. If you use the Win32 API for the specific purpose of random or sequential access, then these settings should be specified as part of the program. I will try them out tomorrow, and see.

**_Elixia_** · 09-24-2003

Don't forget that "fopen" also has these flags, although I don't think they are in the standard, but are specific to certain compilers (which kinda goes against these tests, but anyway).

For example, in MSVC++, the following are the same:

FILE_FLAG_RANDOM_ACCESS in CreateFile &
"rR" in fopen.

FILE_FLAG_SEQUENTIAL_SCAN in CreateFile &
"rS" in fopen.

Although these flags are mentioned as compiler specific, I wonder how many compilers actually support them? Since bad characters are normally ignored, by placing them at the end of the format string, it should increase speed under compilers that support it and be ignored on ones that dont

BTW, It seems that FILE_FLAG_RANDOM_ACCESS simply causes Windows to not do read-ahead caching, but to just cache what you read instead and hold it for a while, whilst FILE_FLAG_SEQUENTIAL_SCAN fully enables read-ahead caching, and throws out earlier information quicker (as it assumes you'll not need it anymore).

EDIT: I'm not sure what happens when neither of these flags are specifies (not tested)

**Cat** · 09-24-2003

Originally posted by FillYourBrain

side note: I don't know if you've ever seen the IJG jpeg library or the gzip code but they both use macros to wrap the reading and writing. And for windows, they use API calls!!

So does paintlib -- I wrote some of the Win32-specific code, in fact. It uses memory-mapped file I/O on Win32 systems.

**_Elixia_** · 09-24-2003

Originally posted by Cat
So does paintlib -- I wrote some of the Win32-specific code, in fact. It uses memory-mapped file I/O on Win32 systems.

Slightly off-topic question, but when you do your memory-mapped I/O, how do you guarantee that you are still within valid file memory? Do you simply wrap all memory accesses using the size of the file, ask windows via IsBadReadPtr() or similar, or simply rely on the fact that you'll not get bad pointers?

**Cat** · 09-24-2003

Originally posted by _Elixia_
Slightly off-topic question, but when you do your memory-mapped I/O, how do you guarantee that you are still within valid file memory? Do you simply wrap all memory accesses using the size of the file, ask windows via IsBadReadPtr() or similar, or simply rely on the fact that you'll not get bad pointers?

Because the file class is derived from an ABC, the file I/O is hidden behind an abstraction. The size of the source or sink is contained within the class. For output, where the precise file length will not be known, the library overallocates for a worst-case scenario and truncates the file at the end.

**JasonD** · 09-25-2003

Originally posted by _Elixia_
For example, in MSVC++, the following are the same:

FILE_FLAG_RANDOM_ACCESS in CreateFile &
"rR" in fopen.

FILE_FLAG_SEQUENTIAL_SCAN in CreateFile &
"rS" in fopen.

Although these flags are mentioned as compiler specific, I wonder how many compilers actually support them? Since bad characters are normally ignored, by placing them at the end of the format string, it should increase speed under compilers that support it and be ignored on ones that dont

Thanks for the information. I could not find this information on the MSDN page for fopen. I was wondering where you found it? I will try them out in my test program.

**_Elixia_** · 09-25-2003

I did find them specified on a website. Although I can't remember the website it was on, it was certainly not in the Microsoft domain.

Anyway, these flags are present in the sources of the Microsoft C runtime library:

D:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\crt\src\_open.c (_openfile())

called from:

D:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\crt\src\fopen.c (fopen())

I do find it strange that they are documented on a third party website, but not on Microsoft's website, who are the creator of this library.

**JasonD** · 09-26-2003

I have made a program to test sequential access speeds:

3 different tests are perform for the C runtime library, and 3 more for the Win32 API. The 3 tests for each are as follows:

1. regular setting
2. sequential read setting
3. random access setting

(i.e "rb", "rbS", "rbR" for C runtime,
0, FILE_FLAG_SEQUENTIAL_SCAN, FILE_FLAG_RANDOM_ACCESS for Win32 API).

Each of the total 6 tests uses a different file, 65 MB in size, and is read into a 1 MB buffer sequentially. Each test is performed one after the other, and then the whole process is repeated. I have 512 MB of RAM on my system, so all 6 files could be cached in memory at the same time, if desired by the OS. The results are below:

Code:

test:         rb     rbS     rbR       0     SEQ    RAND
Rep # 0:    3595    3565    1593    3815    3195    1532
Rep # 1:     280    3285     260     261    2824     260
Rep # 2:     281    2483     251     280    2554     250
Rep # 3:     270    2434     250     281    2583     261
Rep # 4:     270    2133     261     270    2514     260
Rep # 5:     280    2274     260     260    2514     251
Rep # 6:     260    2253     261     270    2534     260
Rep # 7:     270    2234     260     270    3075     260
Rep # 8:     280    2835     260     270    2814     261
Rep # 9:     270    2804     251     280    2774     250
Rep #10:     271    2824     260     270    3214     251
Rep #11:     280    2764     260     271    2814     260
Rep #12:     280    2794     261     270    2424     260
Rep #13:     271    2824     260     270    1853     260
Rep #14:     271    2053     260     271    1852     261
Rep #15:     280    2774     260     271    1862     251
Rep #16:     270    2804     261     280    1963     260
Rep #17:     271    3024     260     271    1822     261
Rep #18:     270    2814     261     270    1913     260
Rep #19:     270    2033     251     280    2734     260
Rep #20:     271    2333     251     280    2804     260
Rep #21:     261    1883     260     270    2894     261
Rep #22:     280    2714     261     270    3034     261
Rep #23:     280    1673     260     280    2764     261
Rep #24:     270    2814     270     271    2864     260
Rep #25:     261    3014     260     271    2824     260
Rep #26:     281    2894     260     271    2663     251
Rep #27:     260    2894     261     270    2744     260
Rep #28:     271    1612     261     270    2694     260
Rep #29:     271    2814     260     270    2754     261
Rep #30:     270    2774     261     270    2834     260
Rep #31:     281    2824     260     281    2784     260
-----------------------------------------------------------
avg:         376    2601     300     382    2609     298

You'll notice the slower times for the first rep, and you'll notice that the sequential read setting does get rid of the cached data, assuming that you will not be reading it again (as shown by the slow speeds after the first rep), where as the other two tests do not (they are much faster after the first rep, as it is still cached). The speeds for C runtime vs Win32 API are about the same, the Win32 API being slightly faster (the clock is accuracy to only 10 ms).

The surprising thing is that the random access (for the first rep - the one that actually matters) is almost twice as fast as the sequential access - even though these files are being accessed sequentially. Why? I have no idea... It's hard to get an accurate test because Windows is already trying to cache the files from previous runs. This test was run after a test on 650 MB files, to ensure there is no possible way these 6 files were cached prior to running the test.

If anyone wishes to run my program on their system, let me know, and i'll make it available. I will post results re: random access later.

My conclusions thus far, given that the win32 api appears to be at least slightly faster in all occasions, is that you should use the win32 api for file access. I agree that these should be under wrappers for portability. Despite the fact that the C functions are portable as is, with wrappers, the Win32 API functions will only require a few lines of code to change during porting, which is really not a big deal, at all.

**JasonD** · 09-26-2003

Here is the same test on 6 files that are 650 MB, all read into the same 1MB buffer, on a WinXP machine with 512 MB of RAM:

Code:

test:         rb     rbS     rbR       0     SEQ    RAND
Rep # 1:   37794   32547   17205   37884   28341   15893
Rep # 2:   47248   29823   17215   33378   28981   21071
Rep # 3:   37704   28671   24756   46526   17416   15722
Rep # 4:   37534   28561   22563   37534   27900   15442
Rep # 5:   59135   18567   16393   33629   27820   15402
Rep # 6:   45155   28721   16414   29542   44264   19969
Rep # 7:   35270   28662   16483   53237   28070   15683
Rep # 8:   34660   46517   16654   38445   27920   15643
Rep # 9:   48179   29322   16283   30594   27790   29843
Rep #10:   27420   31485   16594   37043   42481   16304
Rep #11:   34179   28371   15953   52255   28591   20139
Rep #12:   37033   25727   17686   29302   28681   26729
Rep #13:   53436   32587   16644   38826   24796   16664
Rep #14:   32867   28391   16343   60827   28701   15833
Rep #15:   34139   40519   20088   37995   23564   16123
Rep #16:   58585   20138   16563   37174   28280   15492
Rep #17:   52065   29172   17335   35731   28731   15983
Rep #18:   37214   28441   16213   49932   35992   15702
Rep #19:   37214   38896   16734   31345   24135   15562
Rep #20:   54629   30684   21731   38325   28291   20890
Rep #21:   35781   28612   16684   60917   20870   15963
Rep #22:   44965   28771   16484   54639   28251   15502
Rep #23:   37955   25857   16443   35922   35471   15823
Rep #24:   64513   28831   16123   34910   30955   16384
Rep #25:   37624   35991   16624   47829   28051   15732
Rep #26:   36653   39737   16263   37434   27720   15503
Rep #27:   57843   20099   16513   31476   39026   18196
Rep #28:   33889   28501   16193   61278   28842   15582
Rep #29:   38535   39257   17755   33618   27880   16073
Rep #30:   52716   31836   16053   35291   28050   21120
Rep #31:   34250   28631   17675   33368   58344   24015
Rep #32:   35311   28741   32367   31445   27760   15552
---------------------------------------------------------
avg:       42234   30333   17844   40239   30061   17672

**JasonD** · 09-26-2003

I modified the same program to try random access. Instead reading in the 65 MB file sequentially, it reads 1 MB from it, at random places, 512x in a row. It tries all 3 settings for both the C runtime and Win32 API. Here are the results:

Code:

test:         rb     rbS     rbR       0     SEQ    RAND
Rep # 1:    4407   13880    4236    4066   12287    3926
Rep # 2:    2083   10165    1992    2093   10866    2043
Rep # 3:    2163   14371    1993    2103   11116    1993
Rep # 4:    2083   13619    2013    2093    9694    1993
Rep # 5:    2093    9413    2003    2103   10285    1993
Rep # 6:    2093   10996    1993    2103   10805    1983
Rep # 7:    2113   10695    1993    2093   10916    2003
Rep # 8:    2113   11967    2003    2113    9183    2003
Rep # 9:    2093    9584    2003    2113    9373    2003
Rep #10:    2093   10025    2003    2103    9303    2003
Rep #11:    2093   11276    2003    2113   10555    2003
Rep #12:    2103    9093    2013    2103    9944    1983
Rep #13:    2113    9794    2003    2113    9254    2002
Rep #14:    2103    9074    2002    2093   10906    1993
Rep #15:    2113    9023    2003    2103   10976    2003
Rep #16:    2113    9834    2013    2093   10084    2003
Rep #17:    2103    9544    2003    2103    9493    1993
Rep #18:    2113   10005    2002    2094    9523    2003
Rep #19:    2103    9834    1993    2113    8933    2003
Rep #20:    2103    9754    2063    2143   10665    2003
Rep #21:    2103   11807    2003    2103    9784    1993
Rep #22:    2113    9734    2003    2123    8923    1993
Rep #23:    2103   10495    2013    2103    9303    2003
Rep #24:    2113   10926    2013    2093   10495    1993
Rep #25:    2113   10104    2003    2123   10255    2003
Rep #26:    2113    9423    2003    2113    9854    2013
Rep #27:    2113    9744    2003    2113   10375    1993
Rep #28:    2123    9284    2012    2103   10045    2003
Rep #29:    2153   17455    2013    2113    8893    2023
Rep #30:    2113   10565    2023    2113   10184    2013
Rep #31:    2123   10606    2012    2124    9063    2002
Rep #32:    2124    9012    2013    2113   10325    2003
-----------------------------------------------------------
avg:        2181   10659    2076    2168   10051    2061

As you can see, the setting for random access is the best, but only slightly better than the regular setting. The sequential setting obviously dumps the cache, assuming that it will not need to be accessed again.

**_Elixia_** · 09-26-2003

Nice work Jason! I know it can be done easily enough, but could you include %-age speed increase on each line, which is the result of using Win32 API over C-api?

**JasonD** · 09-29-2003

Yes, I will add this, and re-run the program. I will post the results later today (I run the tests over breaks when I am not at the computer).

I should have done this beforehand, but I guess I thought the numbers were so close that it did not really matter. I hope that everyone now understands the difference of the original test (re-reading the same portion of the same file over and over again) compared to these tests (reading an entire file once, sequentially, and randomly accessing small portions of a very large file). I believe these tests are far more accurate as an emulation of most real-world applications.

**FillYourBrain** · 09-29-2003

wow, you're really putting some time into this. Good work. I kicked out my test in about 10 minutes which is why it isn't very complete. It's only that there's only so much time I'm willing to devote to testing. Still, your tests seem consistent with the original. This is good.

While I still dispute the un- "real world" - edness of reading a single file many times, it is good to have more information now. There are only so many applications that read more than one file at a time. File servers obviously do. A good many do not. Walk through the programs on your system. MS word, MS excel, Photoshop, etc... aside from ini or registry reading, these mostly work off of a single file. Scanning, writing, reading from that file is their job. The software I work on at my job certainly spends its time in one or two files at the same time. I can't see your perspective of what is real world.

**JasonD** · 09-29-2003

To be honest, I am spending more time on this than I first desired, so I understand why you made your program in 10 minutes... But, your results bothered me enough that I had to make my program. I truly believe your program does not emulate any professional real world program, and that my program only emulates most real-world programs in 2 specific cases:

1. when reading a file sequentially - a one shot deal.
2. random access to a file larger than available RAM.

My program should be improved to emulate a large file that may or may not fit in available RAM, which is read and written to. The basis of these above conclusions is as follows:

I agree that most programs work on a single large file. It is my hypothesis that these programs do not read, and re-read the same section of unchanged data multiple times, like your program, and mine, both do. I would think that in these cases, these sections of the file are manually cached to memory. If these sections need to be accessed again, the program should use its memory copy, not read from the file again. If these sections need to be changed, and then the program needs to access the new changed data, then it should also do this directly in memory. Only when the data is deemed 'complete' (for lack of a better word, meaning we needn't access/change the data anymore, at least anytime soon), it is written back to the file.

Of course, sometimes you have to write back stuff that is not 'completed' due to insufficient memory, BUT, your test does not allow the computer to run out of memory, as the file sizes were too small. I made sure to perform my random access test on a file larger than available RAM. Better... but not really good enough.

Maybe I'll try and include reading/changing/writing data, like some large programs may do, on a file both smaller and larger than available RAM. I think THIS is the way most real-world applications work - taking care to not re-read the same unchaged data... hmmm, do you think professional programmers get lazy, and instead of writing their own memory manager, that they just ask for the data directly from the file again, assuming Windows will help them enough? Do you think people change data in the file by reading/changing/writing, and then reading again when the data is needed again? I suppose this is possible... but very, very ugly...

**JasonD** · 09-29-2003

Originally posted by _Elixia_
Nice work Jason! I know it can be done easily enough, but could you include %-age speed increase on each line, which is the result of using Win32 API over C-api?

I have re-done the same 3 tests above with the additional information. The %-ages are how fast the C runtime library is compared to the Win32 API. If it is < 100%, then C runtime is slower. If it is > 100%, then C runtime is faster.

Code:

SEQUENTIAL READ - 650 MB FILES INTO 1 MB BUFFER, 512 MB of RAM.

File access speed test - C runtime vs Win32 API - By: Jason Doucette
-----------------------------------------------------------------------------
type:       C       C       C   Win32   Win32   Win32   C spd   C spd   C spd
test:      rb     rbS     rbR       0     SEQ    RAND  % of W  % of W  % of W
-----------------------------------------------------------------------------
 # 1: 38583ms 29376ms 18299ms 29578ms 39269ms 16608ms     76%    133%     90%
 # 2: 30448ms 18459ms 17768ms 62373ms 29583ms 16590ms    204%    160%     93%
 # 3: 34691ms 29310ms 31884ms 33641ms 29441ms 15804ms     96%    100%     49%
 # 4: 49692ms 42064ms 16355ms 28803ms 18037ms 36523ms     57%     42%    223%
 # 5: 39686ms 29085ms 16147ms 46058ms 31446ms 15406ms    116%    108%     95%
 # 6: 40074ms 28243ms 23231ms 35188ms 27918ms 15679ms     87%     98%     67%
 # 7: 39540ms 24375ms 16226ms 38414ms 27980ms 15534ms     97%    114%     95%
 # 8: 55819ms 29943ms 16088ms 34801ms 35100ms 16755ms     62%    117%    104%
 # 9: 36575ms 28526ms 16047ms 49908ms 29157ms 16306ms    136%    102%    101%
 #10: 34368ms 47799ms 16438ms 38339ms 27832ms 15498ms    111%     58%     94%
 #11: 49350ms 19733ms 20685ms 34123ms 28871ms 35641ms     69%    146%    172%
 #12: 34898ms 28836ms 16196ms 41028ms 21539ms 15863ms    117%     74%     97%
 #13: 39051ms 29179ms 17150ms 55804ms 28790ms 15879ms    142%     98%     92%
 #14: 38805ms 32995ms 17485ms 29575ms 28237ms 15763ms     76%     85%     90%
 #15: 58967ms 17833ms 16267ms 37530ms 28987ms 15751ms     63%    162%     96%
 #16: 58282ms 28926ms 16138ms 38386ms 29024ms 16112ms     65%    100%     99%
 #17: 34709ms 28559ms 17299ms 50745ms 28190ms 16698ms    146%     98%     96%
 #18: 33093ms 48236ms 18468ms 37536ms 28303ms 15559ms    113%     58%     84%
 #19: 56813ms 17468ms 19634ms 31420ms 27828ms 34452ms     55%    159%    175%
 #20: 34072ms 32461ms 17430ms 36229ms 26032ms 15845ms    106%     80%     90%
 #21: 33015ms 28758ms 16505ms 65473ms 30023ms 16073ms    198%    104%     97%
 #22: 35532ms 40782ms 16417ms 38223ms 28385ms 15736ms    107%     69%     95%
 #23: 58790ms 20708ms 16484ms 35724ms 28163ms 15589ms     60%    136%     94%
 #24: 50172ms 29342ms 17296ms 36213ms 36416ms 15823ms     72%    124%     91%
 #25: 38030ms 29128ms 15938ms 48190ms 28296ms 16184ms    126%     97%    101%
 #26: 34417ms 42479ms 16651ms 39396ms 28207ms 16306ms    114%     66%     97%
 #27: 58497ms 30125ms 16363ms 33000ms 16539ms 35355ms     56%     54%    216%
 #28: 37700ms 29349ms 16222ms 43848ms 21196ms 15645ms    116%     72%     96%
 #29: 37676ms 19752ms 16026ms 47847ms 29190ms 15839ms    126%    147%     98%
 #30: 32341ms 48445ms 16709ms 32402ms 19912ms 15987ms    100%     41%     95%
 #31: 46864ms 29253ms 17534ms 34204ms 27690ms 15573ms     72%     94%     88%
 #32: 56116ms 28876ms 16154ms 32780ms 34765ms 17129ms     58%    120%    106%
-----------------------------------------------------------------------------
avg:  42395ms 30262ms 17610ms 39899ms 28135ms 18422ms     94%     92%    104%

The above times are pretty erratic. The 650 MB files are certainly using up as much memory as possible on my 512 MB system, and it appears the prior tests effect future tests. Should they? I have no idea... There is no data being written back to disk, so I would think this memory used for cache would be available for use on the next file in an insignificantly small amount of time.

Code:

SEQUENTIAL READ - 65 MB FILES INTO 1 MB BUFFER, 512 MB of RAM.

File access speed test - C runtime vs Win32 API - By: Jason Doucette
-----------------------------------------------------------------------------
type:       C       C       C   Win32   Win32   Win32   C spd   C spd   C spd
test:      rb     rbS     rbR       0     SEQ    RAND  % of W  % of W  % of W
-----------------------------------------------------------------------------
 # 1:  3574ms  1635ms  1649ms  3666ms  2977ms  1777ms    102%    182%    107%
 # 2:   289ms  3198ms   265ms   275ms  1820ms   261ms     95%     56%     98%
 # 3:   293ms  2910ms   265ms   281ms  2842ms   263ms     95%     97%     99%
 # 4:   295ms  3576ms   273ms   282ms  3964ms   265ms     95%    110%     97%
 # 5:   296ms  3787ms   262ms   273ms  2809ms   261ms     92%     74%     99%
 # 6:   299ms  1614ms   263ms   282ms  2722ms   261ms     94%    168%     99%
 # 7:   290ms  3189ms   264ms   284ms  2931ms   261ms     97%     91%     98%
 # 8:   292ms  1629ms   263ms   276ms  2910ms   262ms     94%    178%     99%
 # 9:   293ms  1624ms   264ms   277ms  2697ms   263ms     94%    166%     99%
 #10:   296ms  1618ms   263ms   278ms  2674ms   265ms     93%    165%    100%
 #11:   302ms  1696ms   266ms   278ms  2619ms   266ms     92%    154%    100%
 #12:   307ms  1633ms   263ms   278ms  2646ms   261ms     90%    162%     99%
 #13:   304ms  3682ms   264ms   277ms  2797ms   265ms     91%     75%    100%
 #14:   295ms  2850ms   263ms   278ms  2846ms   263ms     94%     99%    100%
 #15:   295ms  3203ms   266ms   278ms  1913ms   261ms     94%     59%     98%
 #16:   295ms  2866ms   265ms   276ms  1921ms   261ms     93%     67%     98%
 #17:   292ms  1801ms   267ms   280ms  1945ms   262ms     95%    107%     98%
 #18:   291ms  1956ms   266ms   283ms  1930ms   264ms     97%     98%     99%
 #19:   295ms  1850ms   265ms   283ms  1637ms   262ms     95%     88%     98%
 #20:   295ms  1840ms   264ms   275ms  1628ms   262ms     93%     88%     99%
 #21:   295ms  1878ms   264ms   278ms  1646ms   262ms     94%     87%     99%
 #22:   295ms  2914ms   264ms   280ms  2790ms   261ms     94%     95%     98%
 #23:   299ms  2826ms   265ms   276ms  2752ms   264ms     92%     97%     99%
 #24:   301ms  2781ms   263ms   278ms  2731ms   262ms     92%     98%     99%
 #25:   293ms  1819ms   266ms   281ms  1657ms   261ms     95%     91%     98%
 #26:   304ms  1793ms   264ms   275ms  1612ms   262ms     90%     89%     99%
 #27:   295ms  1738ms   265ms   279ms  1564ms   264ms     94%     89%     99%
 #28:   303ms  2819ms   266ms   279ms  2732ms   263ms     92%     96%     98%
 #29:   294ms  2860ms   266ms   285ms  1556ms   262ms     96%     54%     98%
 #30:   299ms  2835ms   266ms   278ms  2742ms   263ms     92%     96%     98%
 #31:   300ms  1659ms   263ms   284ms  1565ms   262ms     94%     94%     99%
 #32:   297ms  1700ms   265ms   278ms  1567ms   263ms     93%     92%     99%
-----------------------------------------------------------------------------
avg:    398ms  2368ms   308ms   384ms  2348ms   309ms     96%     99%    100%

Since all 6 files can be cached into memory on my 512 MB system, the only results that matter are those from the first test. Do prior tests effect future ones? I would assume no, as they access different files, and I have enough memory that the caching of one should not need any memory from another. Also, the settings for sequential read is not even as good as the settings for random access... This really makes no sense. Btw, I booted the system before every test, to ensure that no caching was done on the files for the first run. The Win32 API fails miserably here... why?

Code:

RANDOM ACCESS READ - 65 MB FILES INTO 1 MB BUFFER, 512 MB of RAM.
512 1-MB reads (from random location each time) per test

File access speed test - C runtime vs Win32 API - By: Jason Doucette
-----------------------------------------------------------------------------
type:       C       C       C   Win32   Win32   Win32   C spd   C spd   C spd
test:      rb     rbS     rbR       0     SEQ    RAND  % of W  % of W  % of W
-----------------------------------------------------------------------------
 # 1:  7647ms  4432ms  4215ms  4303ms 13581ms  4613ms     56%    306%    109%
 # 2:  2369ms 15441ms  2045ms  2303ms 12262ms  1946ms     97%     79%     95%
 # 3:  2385ms 10274ms  2035ms  2308ms 14884ms  1963ms     96%    144%     96%
 # 4:  2385ms 11208ms  2060ms  2304ms 10151ms  1955ms     96%     90%     94%
 # 5:  2376ms  9315ms  2047ms  2310ms  9579ms  1966ms     97%    102%     96%
 # 6:  2379ms 10035ms  2043ms  2322ms  9921ms  1950ms     97%     98%     95%
 # 7:  2376ms  9632ms  2039ms  2316ms 10328ms  1979ms     97%    107%     97%
 # 8:  2478ms 11084ms  2048ms  2327ms  9489ms  1958ms     93%     85%     95%
 # 9:  2382ms  9955ms  2096ms  2333ms 10075ms  1954ms     97%    101%     93%
 #10:  2371ms 10073ms  2014ms  2307ms  9388ms  1954ms     97%     93%     97%
 #11:  2384ms 11186ms  2053ms  2317ms  8955ms  1947ms     97%     80%     94%
 #12:  2391ms  9666ms  2061ms  2307ms 10546ms  1961ms     96%    109%     95%
 #13:  2375ms 10479ms  2060ms  2315ms  9506ms  1957ms     97%     90%     95%
 #14:  2374ms  9187ms  2042ms  2320ms 11029ms  1977ms     97%    120%     96%
 #15:  2386ms  8968ms  2042ms  2315ms 10454ms  1944ms     97%    116%     95%
 #16:  2390ms  8891ms  2050ms  2313ms 10444ms  1973ms     96%    117%     96%
 #17:  2389ms  9498ms  2043ms  2323ms  9858ms  1949ms     97%    103%     95%
 #18:  2396ms 10038ms  2051ms  2314ms  9528ms  1959ms     96%     94%     95%
 #19:  2379ms  9501ms  2046ms  2323ms  9004ms  1949ms     97%     94%     95%
 #20:  2392ms  9305ms  2026ms  2333ms 10077ms  1961ms     97%    108%     96%
 #21:  2471ms 12002ms  2039ms  2311ms  9947ms  1968ms     93%     82%     96%
 #22:  2392ms 10027ms  2039ms  2318ms  9046ms  1957ms     96%     90%     95%
 #23:  2384ms 10629ms  2035ms  2319ms  9454ms  1951ms     97%     88%     95%
 #24:  2397ms 10559ms  2034ms  2323ms  9919ms  1960ms     96%     93%     96%
 #25:  2391ms  9462ms  2088ms  2383ms 11285ms  1957ms     99%    119%     93%
 #26:  2394ms  9542ms  2067ms  2325ms  9866ms  1963ms     97%    103%     94%
 #27:  2387ms  9707ms  2052ms  2320ms 10256ms  1957ms     97%    105%     95%
 #28:  2405ms  9032ms  2050ms  2321ms  9933ms  1959ms     96%    109%     95%
 #29:  2394ms 10374ms  2070ms  2312ms  8873ms  1964ms     96%     85%     94%
 #30:  2406ms 10485ms  2053ms  2327ms  9373ms  1984ms     96%     89%     96%
 #31:  2430ms 10078ms  2042ms  2325ms  9171ms  1972ms     95%     91%     96%
 #32:  2390ms  8826ms  2031ms  2323ms 10186ms  1952ms     97%    115%     96%
-----------------------------------------------------------------------------
avg:   2557ms  9965ms  2116ms  2381ms 10199ms  2042ms     93%    102%     96%

This random access test is reading the same, unchanged data, unlike a real world situation. I will try and find some time to modify this test to allow changing the data, and writing it back to memory, using a simple memory manager, much like a real world application would. I think this test, when finished, will show the most accurate results of emulating a real world situation. Any thoughts?