Can a FastWriter ever be recycled in the current model?
Alex Twisleton-Wykeham-Fiennes <[email protected]> Thu, 16 Mar 2006 11:01:29 +0000
| Newsgroups | gmane.comp.java.webmacro.user |
|---|---|
| Message-ID | <[email protected]> |
All,
I'm having a little look at memory consumption now.
The biggest culprit (by a factor of 2) in terms of size of allocated memory
across a couple of hundred requests is byte[] buffers with the size
percentages given as:-
24% ByteBufferOutputStream.ensureCapacity()
17% JDBC
16% Tomcat
9% ByteBufferOutputStream.getBytes()
8% FastWriter()
4% Buffer.getBytes()
4% ByteBufferOutputStream.reset()
4% ByteBufferOutputStream()
3% JDBC
2% Tomcat
1% StreamTemplate()
...
at a cursory glance, the only one that seems relatively obvious to remove is
the ByteBufferOutputStream.reset() which currently is implemented as:-
/**
* Clear the contents of the byte buffer. Also shrinks the byte buffer
* to the size specified during construction of this ByteBufferOutputStream
*/
public void reset ()
{
_pos = 0;
_buf = new byte[_initialSize];
}
This is currently (in my testbed) only ever getting invoked during:-
ByteBufferOutputStream.reset()
FastWriter.flush()
FastWriter.close()
WMTemplate.evaluateAsBytes()
My questions are:-
- is the FastWriter ever actually recycled? It feels a bit like there was a
thought to recycle the FastWriters at some point, but currently (I think) all
FastWriters are being allocated via the FastWriter.getInstance() methods that
all allocate a new FastWriter instance.
- if the FastWriter *is* recycled and the reset() funtion is actually
required, then does it really matter if there is garbage in the buffer of the
ByteBufferOutputStream left over from the earlier usage? Surely so long as
the pointer is reset back to the 0 point then everything is fine?
The only issue with this that I can see is that if you were to create a very
big ByteBufferOutputStream and then recycle it many times for small tasks,
then you would hold onto a big byte[] array for a long time, but my feeling
is that this is a minority case and not allocating a 4k (or
FastWriter.DefaultBufferSize if defined) block of memory each time you finish
doing your useful work with the buffer is a no-brainer.
If you just comment out the _buf = new byte[_initialSize] then all the unit
tests still pass, but you immediately lose the 4% of memory comsumption, and
gain the speed increase from not allocating the memory or having to garbage
collect it.
Alex
ps any news on CVS status? It's getting harder to keep track of what is
experimental in my tree and what has been tested and posted to the list...
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642