I've been looking at the code for this class and noticed that the scheme for growing the buffer size is pretty inefficient. Basically it has an 8K buffer and when that buffer is exceeded, it allocates a new buffer 8K bigger and arraycopy's the old buffer into it. In a tag with a large body (say half a meg or so) this results in a lot of unnecessary heap growth, garbage collection, and waaay too many arraycopies. In some version I've seen code which double's the buffer size with each growth, which is more efficient, but potentially more wasteful of memory as well.
This seems like a perfect job for an object pool of pages which can be allocated to the buffer and then returned to the pool when no longer needed. The number of buffers needed can be quite high, but they are very transient. In most cases, the lifetime of the tag is much less than a second, so pages would get returned to the pool quickly. This would eliminate all the garbage collection and arraycopies. I think it would then be reasonable to make the buffer size quite a lot smaller, say 512 bytes, or 1K, which would cover the case of tags with very short body content more efficiently as well. The only thing I'm not sure about is knowing when it's safe to return the pages to the pool - it seems like it could be done at the end of writeOut(), but I'm not sure if there are any wierd situations where writeOut could get called more than once. If nobody sees any obvious problems with this scheme, I'll undertake to try it out and provide a patch for it. This code hasn't changed signifigantly since Tomcat 3.2, so it could be refitted in all the versions quite easily. -- Rob -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
