The javadoc for java.io.BufferedReader says It is therefore advisable to wrap a BufferedReader around any Reader whose read() operations may be costly, such as FileReaders and InputStreamReaders. but just how much difference does it really make?

Well, I've been working on my alternative XSLT syntax and the performance wasn't what it should have been. Using a standard XML parser all of the XSLT for docbook can be read and converted into a transformer in about 13.2 seconds. Using the alternative syntax the same operation took 85.8 seconds.

Using the -Xrunhprof options for java showed that about 61% of the time was being spent in java.lang.Throwable.fillInStackTrace. This looked odd.

The trace info showed that the actual exception being thrown was sun.io.ConversionBufferFullException, and the closest I could find in the source was the convertInto method in java.io.InputStreamReader where it catches a ConversionBufferFullException. So, I suddenly thought, as you've probably realised all along, was I using a BufferedReader or not?

I looked and saw that I wasn't so I added one. The time taken for the alternative syntax now went down to 13.7 seconds! This is pretty amazing, not just because of the time saved but because the thing that was slowing everything down was the creation of Exceptions and filling in their stack traces. I would believe not using a buffer would be less efficient, but the reason why was a bit of a surprise.