On 21/03/2013 16:57, Caldarale, Charles R wrote: >> From: Nick Williams [mailto:nicho...@nicholaswilliams.net] >> Subject: Re: svn commit: r1459389 - >> /tomcat/trunk/java/org/apache/tomcat/util/codec/binary/BaseNCodec.java > >>> - private static final int DEFAULT_BUFFER_SIZE = 8192; >>> + private static final int DEFAULT_BUFFER_SIZE = 128; > >> Wow. THAT change alone had an order of magnitude impact? That's >> fascinating... > > And counterintuitive. Bigger is not always better, it seems. Is there a > quick explanation, or should we go read the code?
The test was doing 1,000,000 iterations of a Base64 decode and this was the default buffer size for the result. A new buffer was being created on every iteration and it was much bigger than necessary - both for the test and for normal use cases. I didn't look into whether allocation or GC was taking the time. I suspect allocation. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
