From: <Joe...@t-...> - 2011-02-16 11:55:44
|
Hi, > > if you are transmitting a lot of data then using buffering will > > significantly speed up your i/o; > > Is this really true? Why would it be? The term "transmitting" > > suggests to me that this is true more for output than input. > > Was this the intended meaning? > > TCP does its own buffering. I wouldn't expect clisp buffering to > > offer any advantage over that. >It's most certainly still the same: Buffering locally (i.e. in A) always wins, because you spare N-1 times calling overhead. This is true at all levels, e.g. - fetching blocks from your HD (prefer getting 4KB instead of 512 bytes), - fetching data over the network, - fetching data across processes or threads, - local function A calling local function B, - ... Buffering for TCP may win for the simple reason that TCP may coalesce small data into larger chunks, i.e. waiting for you to fill a buffer within X milliseconds. If you feed it a buffer immediately large enough, it won't wait and immediately start sending data. Try out telnet. IIRC I mentioned here years ago how fetching data from Samba one byte at a time was over 200 times (!) slower than asking for large chunks. Samba sent a huge packet (>200 bytes) asking for 1 byte over the network... I.e. the overhead is immense. Likewise for ad hoc protocols: having a server answer in one go all you want to know is generally faster than sending N tiny web service calls. WS-API designers, DO YOU READ THIS? Regards, Jörg Höhle |