Return-Path: Delivered-To: apmail-jakarta-poi-dev-archive@www.apache.org Received: (qmail 3040 invoked from network); 9 Oct 2003 11:11:29 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 9 Oct 2003 11:11:29 -0000 Received: (qmail 37872 invoked by uid 500); 9 Oct 2003 11:11:21 -0000 Delivered-To: apmail-jakarta-poi-dev-archive@jakarta.apache.org Received: (qmail 37841 invoked by uid 500); 9 Oct 2003 11:11:21 -0000 Mailing-List: contact poi-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "POI Developers List" Reply-To: "POI Developers List" Delivered-To: mailing list poi-dev@jakarta.apache.org Received: (qmail 37736 invoked from network); 9 Oct 2003 11:11:20 -0000 Received: from unknown (HELO mail.iinet.net.au) (203.59.3.44) by daedalus.apache.org with SMTP; 9 Oct 2003 11:11:20 -0000 Received: (qmail 30003 invoked from network); 9 Oct 2003 11:04:25 -0000 Received: from unknown (HELO TOOTSIE.iinet.net.au) (203.217.32.86) by mail.iinet.net.au with SMTP; 9 Oct 2003 11:04:24 -0000 Message-Id: <5.1.1.6.0.20031009205920.04e97d88@mail.iinet.net.au> X-Sender: gstamp@mail.iinet.net.au X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 09 Oct 2003 21:03:02 +0930 To: "POI Developers List" From: Glen Stampoultzis Subject: Re: Improving POIFS performance In-Reply-To: <20031009055558.GB13639@polkadot.sixlegs.com> References: <477E84FEC58EC44BB5AA084A18BB11B202B279F8@snowball.asc.com.au> <477E84FEC58EC44BB5AA084A18BB11B202B279F8@snowball.asc.com.au> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_77070371==.ALT" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N --=====================_77070371==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:25 PM 9/10/2003, you wrote: >Yes. Although the changes to POIFS will not have a tremendous initial >impact on performance since HSSF will still be buffering all of the >records (I have ideas for changing that, but it is a lot of work). I was suspecting this to be the case. I was hoping that the performance would be comparable at least and that memory usage would be the same or better. If this is the case we could pick your implementation and run with that and then work towards providing an implementation of HSSF that can take better advantage of the new API. Regards, Glen Stampoultzis gstamp@iinet.net.au http://members.iinet.net.au/~gstamp/glen/ --=====================_77070371==.ALT--