[physfs] question about PHYSFS_read and PHYSFS_write

[Edward Rudd]

buffering api???
I'm running the 0.1.7 version.. wait I just upgaded to 0.1.8.. Ahh
buffering API!!..
Nice!!
wonder how I missed that in the mailing list..
I currently have my own buffering API written in via the iostreams
streambuf class that runs overtop physfs (I believe I posted that a
while back).
I'll take a look at this..
Thanks..

On Fri, 2003-05-02 at 08:04, Ryan C. Gordon wrote:
> > In some drivers, they are identical (it'll read size*count bytes in one
> > block), others will be (theoretically) more efficient to read 8192 bytes
> > in one block, but likely do the exact same thing (size*count) under the
> > hood.
> 
> Some more thoughts:
> 
> ...the _real_ tradeoff is that if you can't read that whole block, you
> get nothing back if you've asked for size=8192 count=1, whereas size=1
> count=8192 will return however many bytes were actually available.
> 
> The smartest move, really, is to use the physfs buffering API and then
> make the read call in whatever way works best for your program. If you do
> it right, then most read calls will run at the about the speed of a
> memcpy() of size*count bytes and the total i/o overhead reduces the more
> you can safely buffer (that is, without running into disk swapping) at
> once.
> 
> Finally, don't ever do i/o, physfs or otherwise, in time-critical loops. I
> assume this is a discussion about lowering startup or mapchange times or
> whatnot, but I figured I should throw that out there anyhow.
> 
> --ryan.
-- 
Edward Rudd <eddie at omegaware.com>