On Mon, 13 Dec 2010, Nick Burch wrote:
Just a heads-up that I'm planning to spending some time while I'm off over
Christmas working on a lower memory POIFS implementation. The idea is to have
it load blocks on demand, in disk instead of logical order, rather than the
current code which loads everything and sorts before use.
Initially I'm aiming for enough support to be able to read the directory
listing, and read streams. I'm not intending to support write, but I do aim
to leave extension hooks in place so it can be added later if anyone wants
to! Performance wise, I suspect it'll be faster to load, but slower to read
streams (due to disk seeks)
I think we're now largely there with this, with all the code in svn trunk.
It still needs to be documented, and not all the POIDocument
implementations can work with it for read (write isn't supported yet)
However, running HPSFPropertiesExtractor against a 9mb file:
* POIFSFileSystem - minimum Xmx 12mb, average time 250ms
* NPOIFSFileSystem - minimum Xmx 2mb, average time 190ms
So, the new code is both lower memory and faster, which seems a result!
Once write support is done, and tested, I'd lean towards making NPOIFS an
option for one release, then rename POIFS to OPOIFS and make NPOIFS the
new default. More on that when they're feature compatible though!
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
