Front page | perl.perl5.porters |
Postings from February 2011
On Tue, Nov 9, 2010 at 2:54 PM, Craig A. Berry <craig.a.berry@gmail.com> wrote:
> I think I'll do making it a macro and changing the default size
> in separate commits so it's easier to cherry pick the former.
I've now finally done the second of these as follows:
% git show
commit b83080de5c42543809ce9004bcdbcd3162a00e70
Author: Craig A. Berry <craigberry@mac.com>
Date: Thu Feb 17 14:24:39 2011 -0600
Increase PERLIOBUF_DEFAULT_BUFSIZ to larger of 8192 and BUFSIZ.
The previous default size of a PerlIO buffer (4096 bytes) was
chosen many years ago before PerlIO was even the default I/O scheme
for Perl. Benchmarks show that doubling this decade-old default
increases read and write performance in the neighborhood of 25%
to 50% when using the default layers of perlio on top of unix.
The only situation without a noticeable performance benefit so
far appears to be when physical I/O is so slow that it dwarfs
any savings from the reduction in layer shuffling, but there
is also no performance penalty in this case.
BUFSIZ will be chosen in the unlikely event that it's larger
than 8192 on the assumption that the system maintainers would
not set such a value without good reason.
If the new size causes problems, or to try an even bigger size,
configure with:
./Configure -Accflags=-DPERLIOBUF_DEFAULT_BUFSIZ=N
where N is the desired size in bytes; it should probably be a
multiple of your page size.
diff --git a/perlio.h b/perlio.h
index 479a44f..0575cb1 100644
--- a/perlio.h
+++ b/perlio.h
@@ -191,7 +191,7 @@ PERL_EXPORT_C void PerlIO_clone(pTHX_
PerlInterpreter *proto,
/* The default buffer size for the perlio buffering layer */
#ifndef PERLIOBUF_DEFAULT_BUFSIZ
-#define PERLIOBUF_DEFAULT_BUFSIZ 4096
+#define PERLIOBUF_DEFAULT_BUFSIZ (BUFSIZ > 8192 ? BUFSIZ : 8192)
#endif
#ifndef SEEK_SET
[end]
There were various useful suggestions in this thread for
Configure-time and run-time options to set the buffer size. I have no
objection to such things but I'm not going to get around to
implementing them anytime soon, if ever, and I thought *something*
ought to be done before 5.14.0 given the dramatic benefits. 8192 is
obviously a bit arbitrary, but using twice as much memory as we did 10
years ago feels pretty safe given that most system memory has
increased by a lot more than a factor of 2 in that timeframe.
There is of course still time to modify or even revert this before
5.14.0 if a good argument for something different comes along. I will
add something to perldelta shortly, but we could have a better
perldelta and/or promotional talking point for 5.14.0 if interested
folks were to do more and different benchmarks (e.g., whether Moose
loads any faster, etc.).
Thread Previous
|
Thread Next