Hi DM,<div><br></div><div>I like your idea of lazy-loading parts of the conf files but see the last point for a simpler thing you may like to try first.</div><div><br></div><div>Regarding your comment '<i>the default resource bundle should not be loaded by the VM if it is not needed</i>' can I check you are not confused by the same issue that confused me for a few days. I did not understand why the default resource bundle was being loaded as well as the English (for me) one. Then I realised that the English bundle modifies the default one rather than overriding it so both bundles need to be loaded. So actually the default bundle will always be loaded.</div>
<div><br></div><div>There is another related issue I have known about for some time but have not mentioned but could speed up the initial loading of conf files. When starting And Bible I get an awful lot of the following messages which I think might be caused by the BufferedReader used to load conf files but I haven't analysed this in detail so it could be any BufferedReader used in JSword. I get the message 22 times on startup and have 10 modules.</div>
<div> Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required.</div><div>Maybe the BufferedReader used to load conf files could be specified to be initially 2k and any other BufferedReaders could also use an appropriate setting.</div>
<div><br></div><div>Best regards</div><div>Martin</div><div><br><div class="gmail_quote">On 29 December 2010 16:53, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org">dmsmith@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000">
We've tried a variation of this. The only difference is that we
don't have localizations of the names in the default property files.
SWORD and the frontends, such as Xiphos, do not have mappings of
codes to names. Xiphos in particular uses a 3rd party lookup to get
them.<br>
<br>
Regarding our lookup:<br>
The default list is a master list of all languages. I update it
about once or twice a year from the official source. It is only in
English. At one time we used a subset of this based upon what was in
the CrossWire repository.<br>
The lookup mechanism needs a default or for the software to do
something reasonable when the lookup fails. If you were to replace
the default with the smaller _en version, you'd get the "Other" name
for the unknown code. (This is the subset that we used.)<br>
<br>
Why did we move away from that?<br>
There was a flurry of new module creation.<br>
* CrossWire got a lot of modules for "minority" languages. Many of
these people groups are small and impoverished. The primary users of
these modules would be pastors, missionaries and perhaps scholars. <br>
* CrossWire got some modules for languages that are well known to
many. E.g. Latin, Old English.<br>
* CrossWire got a bunch of modules for language groups that we
wanted to reach. E.g. Farsi.<br>
* The Xiphos module repository came into its own. Unlike the
CrossWire repository it is updated frequently.<br>
<br>
The basic issue can be summarized:<br>
How would you feel if your primary language was Farsi and you were
looking for Farsi modules? Would you mind finding them in "Other" or
"Unknown"?<br>
<br>
So, I think we should solve these problems:<br>
Slow startup.<br>
There will be several reasons for this. But with regard to this
issue it stems from the confs being fully read and converted into an
internal format, involving a lookup of language codes to get
language names. This process should be made to be "lazy."<br>
<br>
Slow lookup of new language names.<br>
I was under the impression that the default resource bundle should
not be loaded by the VM if it is not needed. We should verify
whether this is the case or not.<br>
If we were to move the list of all languages into a different bundle
or perhaps an entirely different lookup mechanism, that might help.<br>
I think the localized language names would be a better default.
(See: <a href="http://crosswire.org/wiki/Localized_Language_Names" target="_blank">http://crosswire.org/wiki/Localized_Language_Names</a> ) This
might be better for all locales.<br>
<br>
Thoughts?<br>
<br>
In Him,<br><font color="#888888">
DM</font><div><div></div><div class="h5"><br>
<br>
<br>
On 12/29/2010 09:02 AM, Martin Denham wrote:
<blockquote type="cite">Hi,
<div><br>
</div>
<div>David's recent comments on the Sword mailing list seem
relevant. They might imply that a more limited list of
languages might be acceptable and he also mentions the approach
taken by Xiphos. He says:</div>
<blockquote style="margin:0pt 0pt 0pt 40px;border:medium none;padding:0px">
<div>"<span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">Referring to <a href="http://www.crosswire.org/wiki/DevTools:confFiles" style="color:rgb(0, 0, 204)" target="_blank">http://www.crosswire.org/wiki/DevTools:confFiles</a></span></div>
<span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">the
only language related element is lang itself.</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><br>
</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">This
means that when a front-end encounters a new module for which
it cannot<br>
</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">yet
provide a look-up for the localized language name, it will
show Unknown<br>
</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">as
the name of the language. That's what Xiphos does, for
example.</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><br>
</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">As
a fall-back position, might it be sensible to allow the conf
file to<br>
</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">optionally
include the localized language name in addition to the lang<br>
</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">element?</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><br>
</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">This
would be processed as follows:</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><br>
</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">If
the lang identifier can be looked up, use the look-up value.<br>
</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">If
not, then if the conf file includes the localized language
name, use<br>
</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">that.<br>
</span><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">Then
if not either, fall back to using unknown, as at present.<span style="border-collapse:separate;font-family:arial;font-size:small">"</span></span></blockquote>
<div><br>
</div>
<div>Regards</div>
<div>Martin<br>
<br>
<div class="gmail_quote">On 22 December 2010 22:42, Martin
Denham <span dir="ltr"><<a href="mailto:mjdenham@gmail.com" target="_blank">mjdenham@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
I was wondering if we need the iso639 properties files if
the language codes and names returned by the standard Locale
class contained all the codes and names that are in the
large properties file - I don't know if they do. Using
Locale could (I think) also automatically give us locale
specific country names automatically for all Locales
e.g. Angličtina instead of English on Czech mobiles.
<div>
<br>
</div>
<div>I haven't tried this out yet and we are only talking
about 2 secs at startup but I am trying to whittle away
the 17 secs it currently takes to start up JSword-And
Bible. However, this does possibly give other advantages.
<div>
<div><br>
<br>
<div class="gmail_quote">On 22 December 2010 18:04, DM
Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
I've gone back and forth on this one. The goal is
to have names for all the codes. There are a bunch
of minority languages with Bibles in beta that
this covers.<br>
<br>
The simplest solution is to rename the _en file to
be the default.<br>
<br>
The bigger problem is that the confs are fully
read on startup which is in necessary. This is
causing the Lang lookup.<br>
<br>
In Him,<br>
DM<br>
<br>
Cent from my fone so theer mite be tipos. ;)<br>
<div>
<div><br>
On Dec 22, 2010, at 7:07 AM, Martin Denham
<<a href="mailto:mjdenham@gmail.com" target="_blank">mjdenham@gmail.com</a>>
wrote:<br>
<br>
> I have occasionally tried to improve the
slow start-up times of And Bible & JSword
without much success. However, one area which
I have a suspicion may take time is property
file loading.<br>
><br>
> I run out of memory part way through when
profiling startup but I notice
iso639.properties which has 7600 lines can
take 2 seconds to load up on slow phones. I
wonder if, instead of storing the language
codes in properties files we could use methods
like Locale.getDisplayLanguage(loc) and other
Locale methods to completely remove the need
for the iso639 properties files.<br>
><br>
> What do you think?<br>
><br>
> Regards<br>
> Martin<br>
><br>
</div>
</div>
<div>
<div>>
_______________________________________________<br>
> jsword-devel mailing list<br>
> <a href="mailto:jsword-devel@crosswire.org" target="_blank">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>
_______________________________________________<br>
jsword-devel mailing list<br>
<a href="mailto:jsword-devel@crosswire.org" target="_blank">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>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<pre><fieldset></fieldset>
_______________________________________________
jsword-devel mailing list
<a href="mailto:jsword-devel@crosswire.org" target="_blank">jsword-devel@crosswire.org</a>
<a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a>
</pre>
</blockquote>
<br>
</div></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><br></div>