On Tue, Nov 9, 2010 at 5:06 PM, Tom Christiansen <tchrist@perl.com> wrote: > I therefore do not believe that a buffer size that's the same as the VM > pagesize is necessarily optimal. I agree completely. > My hunch is that a bigger one might help. Careful benchmarks would be > needed to prove or disprove, or even substantiate, that hunch. I'm pretty sure the benchmark I posted already demonstrates that on one particular machine with a 4K page size, buffers of 16K or 32K provide much faster perlio performance than a buffer that matches the page size. I welcome improvements on the benchmark and results on platforms with varying page sizes. It might make sense to do page *alignment*, i.e., the buffer size is a multiple of the page size, but I suspect even that is not the most important aspect of this. I'm no performance guru, but the principles I think I (partly) understand imply that coalescing multiple I/O operations into a single operation is likely to be a bigger win even than avoiding the much-dreaded page faults and alignment faults. Not to mention that "coalescing," which may require varying levels of effort for the layers implementing read()/write() on down to the hardware, is for perlio a passive activity: we simply don't flush as often, so we save on shuffling things around inside the interpreter.Thread Previous | Thread Next