Hi all<div><br></div><div>Just wondering if this section of the "Activator" code was introduced to reduce memory as a result of observing an issue, or not? I'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's not used to synchronise on, nor used in any form. The private javadoc comment is slightly mis-leading, unless I'm missing a piece of code somewhere.</li><li>SwordGenBook.activate gets an empty set from its parent, and thereby the loop doesn't do anything.</li>
<li>the "global" 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't want to be sharing the state across threads, and therefore that state needs to be local. Not sure if it'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>