Hi there What started as an experiment turned out to be very interesting. In FOP-land we use a lot of ByteArrayOutputStreams and looking at its source code it makes you wonder if it's really necessary to throw away the whole buffer if it needs to grow. Especially when you consider that java.io.ByteArrayOutputStream starts with a 32 bytes.
So I went ahead and coded my own implementation which doesn't throw full buffers away but stores them in a List. It is designed to behave exactly like the original except that its default initial buffer size is 1024 bytes instead of 32. I left out the deprecated toString(int) method. Attached you will find the implementation along with a TestCase and a Demo class that does some simple performance measurements. Results? On my Windows XP Pro machine with Sun's JDK 1.4.0_03 on a Intel P4 2.4GHz processor: > Warming up JVM... > ============================================= > Measuring...25 runs > ============================================= > Average time Commons: 22ms > Average time java.io: 107ms My implementation produces less garbage and doesn't need to do excessive copying around of buffer content. Seems like this has a major impact. I'd like some feedback. It may be that I've done a mistake in my thoughts. Wouldn't be the first time... :-) Anyway, if you like the code, I'd appreciate if it got included in Commons IO. As a little goodie I've added a NullOutputStream (writes to /dev/null) which comes handy in a number of cases. Jeremias Maerki FOP committer
CommonsByteArrayOutputStreamProposal.zip
Description: Zip compressed data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
