text mode under win32 : treated as binary mode, this could lead to bugs for
It might be worth while, I’m not sure.
Do you know if “t” mode is used on other platform? because if not, then using
"t" with SDL would not be very “portable”. But if yes… this would be a “must
have”.
no buffering at all, some code that do fread/fwrite 2 bytes at time 10000
times could be slowed down dramatically. I could add a “buffer” layer, but again
, does it worth it?
Probably not an issue, but I’m open to suggestion…
Something I wanted to use: FileMapping. Because this should be really fast, even
when doing a loop with 1 byte access. Slow file access <=> user waits for a game
to start
I’m not sure that filemapping can cover all the stdio cases. This is why I
didn’t try it at the first place. If I manage to get some more time, I could try
a test implementation in 1 or 2 weeks
Do you know if “t” mode is used on other platform? because if not, then using
"t" with SDL would not be very “portable”. But if yes… this would be a “must
have”.
Like “b” mode, “t” mode is silently ignored on other platforms.
Something I wanted to use: FileMapping. Because this should be really fast, even
when doing a loop with 1 byte access. Slow file access <=> user waits for a game
to start
I’m not sure that filemapping can cover all the stdio cases. This is why I
didn’t try it at the first place. If I manage to get some more time, I could try
a test implementation in 1 or 2 weeks
Even 1 byte reads are probably pretty fast, since I’m sure the underlying
Win32 API does buffering at some level.
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
I wouldn’t say they’re ignored, that sounds like the calls are broken:
on Unix, they’re processed correctly, its just that “t” is the same
as “b”.
On Cygwin, you have a global choice whether “t” is binary or CR/LF pair
is converted to LF.On Mon, 2006-02-27 at 18:18 -0800, Sam Lantinga wrote:
Do you know if “t” mode is used on other platform? because if not, then using
"t" with SDL would not be very “portable”. But if yes… this would be a “must
have”.
Like “b” mode, “t” mode is silently ignored on other platforms.
Like “b” mode, “t” mode is silently ignored on other platforms.
That sounds good :))
Even 1 byte reads are probably pretty fast, since I’m sure the underlying
Win32 API does buffering at some level.
To be sure, I did some profiling on my PC (Win2K/SP4, P4 2.4Ghz), indeed there
is some buffering.
Good result is on random read() (2x faster)
The bad results are on small read/write (13x to 20x slower), but they are really
bad. Anyway, someone who is reading 4 bytes at a time, sequentially in a file is
somewhat avoiding speed carefully ! :))
With a file, stdio way :
write_test(stdio):0.109000 s (1000000 sequential writes of 4 bytes)
read_test(stdio):0.110000 s (1000000 sequential reads of 4 bytes)
random_read_test(stdio):4.734000 s (1000000 seek(rand()), read 4 bytes)
bigwrite_test(stdio):2.687000 s (1000 x 64kb writes)
bigread_test(stdio):0.047000 s (1000 x 64kb read, of bytes we’ve just written)
With another file, with Win32 API (same conditions)
write_test(winio):1.875000 s
read_test(winio):1.329000 s
random_read_test(winio):2.250000 s
bigwrite_test(winio):2.796000 s
bigread_test(winio):0.047000 s
OK. I will wait. Will you be so kind and inform us when the patch will be in
the CVS. Thank you.
[I am sorry if I seam a bit inpatient, but the problem I am facing is that
the ddl from bug 47 does not work with our version of WinCE and we need to
have a working prototype of our application by 6. of March]
Regards SimonOn 2/28/06, Dmitry Yakimov wrote:
Hi,
I’m still working on the update of new build system for WinCE.
Please wait a few days.
Hi all,
I tried to build the latest CVS for WinCE 4.10 and run into a problem
with
sdl_thread.h. I got:
