[jsword-devel] Memory analysis

[Chris Burrell]

The block size is specified at creation of module and defines the smallest
unit that can be decompressed. So you can't change it later.

Since we support low powered devices this really should be chapter imho or
driven from the frontend and support multiple distributions.

In terms of not nulling some blocks I think that was by design before we
introduced the state objects. It is often the case that frontends will ask
for data that is in the same compressed block.  E.g sequential access to
all verses in chapter...
On 31 May 2014 13:30, "refdoc at gmx.net" <refdoc at gmx.net> wrote:

> 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 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.
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20140531/3a69d6d2/attachment.html>