<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 12/29/2010 12:40 PM, Martin Denham wrote:
<blockquote
cite="mid:AANLkTikWxor3k5FrkH6y24uh=pJ=UZ=4X3zZ2UtWPmfQ@mail.gmail.com"
type="cite">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>
</blockquote>
Then I'll split it into two resources. The full list will only be
used if the code was not found otherwise. We'll see about a
different lookup for the full list. (Ideas??) The load time would
still be unacceptable for the installer's list of available books.
So resource bundle/properties is not workable.<br>
<br>
<br>
<blockquote
cite="mid:AANLkTikWxor3k5FrkH6y24uh=pJ=UZ=4X3zZ2UtWPmfQ@mail.gmail.com"
type="cite">
<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>
</blockquote>
<br>
What was the message? I'd like to see it.<br>
<br>
<br>
<blockquote
cite="mid:AANLkTikWxor3k5FrkH6y24uh=pJ=UZ=4X3zZ2UtWPmfQ@mail.gmail.com"
type="cite">
<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>
</blockquote>
<br>
Ok.<br>
<br>
In Him,<br>
DM<br>
<br>
<blockquote
cite="mid:AANLkTikWxor3k5FrkH6y24uh=pJ=UZ=4X3zZ2UtWPmfQ@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
href="mailto:dmsmith@crosswire.org">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;">
<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 moz-do-not-send="true"
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 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 moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>