[jsword-devel] Memory analysis

[Martin Denham]

*Tidy up omission*
Is it a mistake that
  ZVerseBackendState.lastUncompressed
is not being cleared in
  ZVerseBackendState.releaseResources()
because lastUncompressed can hold a large chunk of memory.

*Large identical byte[] Allocations*
There 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 Type*
Possibly 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=CHAPTER
and 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/427c6318/attachment.html>