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? Thanks Jason Height Systems Engineer ASC -------------------------------------------------------------------------------------------------------------------- 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
