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