pipe performance
pipe performance
Posted Jan 14, 2005 16:45 UTC (Fri) by giraffedata (guest, #1954)Parent article: Circular pipes
I suppose the 30-90% performance gain is for applications that do huge multi-page reads and writes with high latency. For the common case, for which the existing pipe implementation was designed, where there is a steady stream of about 80 byte reads and writes, it is most probably slower due to the additional overhead and the loss of locality of reference.
Also, one doesn't normally want the size of pipe to increase without bound, so I'd say a parameter to limit the size is necessary. I think another parameter should choose between this and the old method.
I don't understand why this is being called "circular." The old method is more circular. In that, the same bytes of buffer get used over and over in a simple circular fashion.
Posted Jan 20, 2005 5:27 UTC (Thu)
by sweikart (guest, #4276)
[Link]
-scott
pipe performance
> For the common case, for which the existing pipe implementation was designed,
> where there is a steady stream of about 80 byte reads and writes ...
Actually, this is not the common case. The common case is that the programs writing to (and reading from) the pipe use stdio; when writing to a device that's not a tty, stdio defaults to block buffering. The block size used by stdio should work well with Linus's scheme (and if it doesn't, it would probably make sense to change it).