<p dir="ltr">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. </p>
<p dir="ltr">Since we support low powered devices this really should be chapter imho or driven from the frontend and support multiple distributions. </p>
<p dir="ltr">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...</p>
<div class="gmail_quote">On 31 May 2014 13:30, "<a href="mailto:refdoc@gmx.net">refdoc@gmx.net</a>" <<a href="mailto:refdoc@gmx.net">refdoc@gmx.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span style="font-family:Arial">Re Gill, best speak directly to Karl<br><br><div>----- Reply message -----<br>From: "Martin Denham" <<a href="mailto:mjdenham@gmail.com" target="_blank">mjdenham@gmail.com</a>><br>
To: "J-Sword Developers Mailing List" <<a href="mailto:jsword-devel@crosswire.org" target="_blank">jsword-devel@crosswire.org</a>><br>Subject: [jsword-devel] Memory analysis<br>Date: Sat, May 31, 2014 13:13<br>
<br></div></span><br><div dir="ltr"><div><b>Tidy up omission</b></div><div>Is it a mistake that</div> ZVerseBackendState.lastUncompressed<div>is not being cleared in</div><div> ZVerseBackendState.releaseResources()</div>
<div>because lastUncompressed can hold a large chunk of memory.</div>
<div><br></div><div><b>Large identical byte[] Allocations</b></div><div>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.</div>
<div><br></div><div>Each of the first 3 lines of uncompress() allocate an identically large chunk of memory:</div><div><div> public ByteArrayOutputStream uncompress(int expectedLength) throws IOException {</div><div> ByteArrayOutputStream out = new ByteArrayOutputStream(expectedLength);</div>
<div> InflaterInputStream in = new InflaterInputStream(input, new Inflater(), expectedLength);</div><div> byte[] buf = new byte[expectedLength];</div></div><div><br></div><div>And a further identical allocation is made in the calling method:</div>
<div><div> uncompressed = CompressorType.fromString(compressType).getCompressor(data).uncompress(uncompressedSize).toByteArray();</div></div><div><br></div><div><b>Gill Block Type</b></div><div>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:<br>
BlockType=BOOK<br><br>Most other commentaries seem to have:<br>BlockType=CHAPTER</div><div>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.</div>
<div><br></div><div>Martin</div><div><br></div><div>Is it just a matter of changing the conf or will the whole module need to be regenerated.</div><div><br></div><div>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.</div>
</div>
<br>_______________________________________________<br>
jsword-devel mailing list<br>
<a href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a><br>
<br></blockquote></div>