[SDL] SDL_RWread *much* slower on Windows in 1.2.10/11

[Christophe Cavalaria]

Holger Schemel wrote:

> 
>> Within your own project, if the stdio codes works, it probably won't
>> STOP working.
> 
> Good to know! Just wasn't sure about Windows targets like Vista I don't
> yet have access to for testing... (But then, dropping support for these
> ANSI-C functions is indeed not that likely, even from Microsoft. ;-) )
> 
>>> If not, it may be worth tuning SDL_image's loading code to use buffered
>>> I/O by itself (by prefetching more bytes internally), if needed (but
>>> this wouldn't be a trivial approach, of course :-/ ).
>> 
>> Probably be better to buffer inside SDL so it works as before and we
>> don't have to clean up every project.
>> 
>> That being said...I don't think it's the buffering. I just checked the
> 
> Also can't really believe this, as several other system layers use
> some kind of buffering (e.g. the hard disk's internal cache etc.),
> so a speed difference in that dimensions (6-8 even after repeated
> invocations, when everything is in the file system's buffer cache
> anyway) seems quite unlikely.
> 
>> MSDN docs and it says it SHOULD be buffering it (there's a flag to
>> explicitly disable buffering in CreateFile() but we don't use it). I
>> guess we'll have to research this further.
> 
> Yep, this indeed seems to be worth some further investigation. Funny
> though that I seem to be the only one who experienced such a huge
> speed difference. (Not sure if the impact on non-PCX image files is
> the same though.)
> 
>> I've added it to the bugtracker:
>>     http://bugzilla.libsdl.org/show_bug.cgi?id=412
> 
> Thanks! (If this reveals to be not easily fixable somehow, it might
> be worth adding a configure option for the mingw built target to
> explicitly choose using the stdio functions.)

I could imagine a reason why it would be slower than the ANSI-C function,
and it has to do with buffering. If the Win32 API resides in the kernel and
needs kernel mode rights, you have to pay for a context switch each time
you call it. Thus, even if the later does some buffering, it could be worth
it to add more buffering above that in the ANSI-C function itself.