[jsword-devel] Memory analysis

[refdoc@gmx.net]

Re Gill, best speak directly to Karl

----- Reply message -----
From: "Martin Denham" <mjdenham at gmail.com>
To: "J-Sword Developers Mailing List" <jsword-devel at crosswire.org>
Subject: [jsword-devel] Memory analysis
Date: Sat, May 31, 2014 13:13
Tidy up omissionIs it a mistake that  ZVerseBackendState.lastUncompressedis not being cleared in  ZVerseBackendState.releaseResources()because lastUncompressed can hold a large chunk of memory.

Large identical byte[] AllocationsThere are 4 identical memory allocations when a passage is decompressed all of byte[expectedSize] but I can't think how to avoid this or even if it is possible.

Each of the first 3 lines of uncompress() allocate an identically large chunk of memory:    public ByteArrayOutputStream uncompress(int expectedLength) throws IOException {        ByteArrayOutputStream out = new ByteArrayOutputStream(expectedLength);
        InflaterInputStream in = new InflaterInputStream(input, new Inflater(), expectedLength);        byte[] buf = new byte[expectedLength];
And a further identical allocation is made in the calling method:
            uncompressed = CompressorType.fromString(compressType).getCompressor(data).uncompress(uncompressedSize).toByteArray();
Gill Block TypePossibly an issue for Xiphos.  Can somebody confirm that the following conf setting is incorrect for a commentary because Gill has extremely large memory requirements and does not run on some small mobiles.  Gill has the following in it's conf:

BlockType=BOOK

Most other commentaries seem to have:
BlockType=CHAPTERand I suspect this means JSword attempts to load a whole Bible book of commentary notes in order to return notes for 1 verse, which will have a large memory requirement.

Martin
Is it just a matter of changing the conf or will the whole module need to be regenerated.
I can raise it with the Xiphos team if somebody confirms my understanding but I raised this on sword-devel several years ago but that was probably the wrong place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20140531/f9a38ff7/attachment.html>