Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
Todd Sabin wrote:
>> >> Reading 1_000_000 bytes [one by one on MS-Windows2k],
>> >> reported real time/run (or "system") time:
>> >> from source: local file Samba/NFS server
>> >> unbuffered 161/132 secs 1866/173 seconds!!
>I'd guess the difference is between NFS and SMB, then. The linux NFS
>implementation is probably reading entire blocks (instead of single
>bytes) across the network, whether you've asked for them or not, but
>the windows SMB implementation is only reading single bytes as you ask
>for them. You can try sniffing the network traffic and seeing if
>that's the case.
I installed ethereal (www.ethereal.com) which I was recommended and can now confirm: Each SMB request for one byte of the file takes 117 bytes and every answer is 118 bytes long on the network. That's 235 times overhead!
My conclusion (unchanged): use buffering in your application! You never know what the OS is going to do on unbuffered/small calls on file/pipe/sockets.
Whether one should thank an application for doing buffering and thus behaving well in many environments or thank the Linux environment (or NFS?) for allowing unbuffered applications not to perform too badly is open to debate.