Hi all<div><br></div><div>Just wondering if this section of the &quot;Activator&quot; code was introduced to reduce memory as a result of observing an issue, or not? I&#39;m looking at SwordGenBook in particular, but seeing all kinds of interesting things</div>
<div><br></div><div><ul><li>Activator has a reduceMemoryUsage method. This is based on KILL. Of the 3 enum constants, only 1 has a method that actually does something. And as far as I can tell, anyone can call reduceMemoryUsage at any time, which will then thoroughly break anything in the process of running by nulling out a whole load of references.</li>
<li>Secondly, there is this Lock object. It&#39;s not used to synchronise on, nor used in any form. The private javadoc comment is slightly mis-leading, unless I&#39;m missing a piece of code somewhere.</li><li>SwordGenBook.activate gets an empty set from its parent, and thereby the loop doesn&#39;t do anything.</li>
<li>the &quot;global&quot; field is always an empty ReadOnlyList as a result, can we remove and simplify this?</li></ul><div>In the SwordBook:</div><div><ul><li>activate() does nothing (apart from registering it with the activator, which seems to defeat the point as there is no clean-up)</li>
<li>deactivate() deactivates the backend it is based upon. Should this be done preferably by the backend rather than here?</li></ul><div>Finally, in order to address JS-109 and contain the refactoring process, I am thinking of changing the method signature for AbstractPassageBook.getRawText(). My intended approach is to pass in an extract parameter, as 1 or 2 anonymous class to post-process what has been discovered in reading the raw data. By doing so, I believe I might be able to push both loops from AbstractPassageBook into the backends, so that the backends themselves deal with iterating through ranges and verses. </div>
</div><div><br></div><div>The idea being, for performance reasons, we want to keep the random access files open and re-use the state. However, we don&#39;t want to be sharing the state across threads, and therefore that state needs to be local. Not sure if it&#39;s going to be feasible doing it that way, but I thought I might give it a go. It obviously might mean re-jigging the vast majority of the backends. Shout if you want some more details.</div>
<div><br></div></div><div>Cheers</div><div>Chris</div><div><br></div>