poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Height, Jason" <JHei...@subcorp.com.au>
Subject DBCell, IndexRecord & ExtSSTRecord patch performance
Date Tue, 18 Feb 2003 23:15:27 GMT
I have investigated the poor performance as a result of the patch that I
wrote for Bug 9576.


Most (95%) of the performance can be recovered with adjustments to the
ValueRecordsAggregate. My patch relies heavily on being able to serialize a
block of cells. A cell block is defined by a start row and end row and
should be serialized in row-cell order. Currently (as I originally noted)
the performance is due to the fact that there is no way to quickly get the
cells for a given row number, the current patch creates an iterator over the
result of the call to values() of the TreeMap FOR EACH ROW THAT IS WRITTEN!.
This iterator is traversed in order from start to finish OVER ALL CELLS not
just for a given row.


Obviously you can imagine the amount of memory being allocated and GC's and
also the amount of work needed to write a block of cells.


To arrive at my performance conclusions I altered the way that cells are
stored (The TreeMap is Keyed by the row number ie new
Integer(cel.getRowNum()) and contains a ArrayList of cells) and also wrote
my own custom iterator that will return the rows in correct order (but I
still need to return the cells for a row in correct order and make sure that
duplicate inserts only insert one cell for a given row and cell number).


I have looked at Andy's implementation of ValueRecordsAggregate in the
performance-branch and this is doing a very similar thing in terms of the
ability to quickly get the cells allocated to a row. To be honest it seems
to be a bit complicated but maybe it needs to be.


Can we merge the performance-branch ValueRecordsAggregate class or should I
continue along my original approach listed above.


When is 1.9 being released?




Jason Height

Systems Engineer



This e-mail (including attachments) is confidential information of Australian Submarine Corporation
Pty Limited (ASC).  It may also be legally privileged.  Unauthorised use and disclosure is
prohibited.  ASC is not taken to have waived confidentiality or privilege if this e-mail was
sent to you in error. If you have received it in error, please notify the sender promptly.
 While ASC takes steps to identify and eliminate viruses, it cannot confirm that this e-mail
is free from them.  You should scan this e-mail for viruses before it is used.  The statements
in this e-mail are those of the sender only, unless specifically stated to be those of ASC
by someone with authority to do so.

View raw message