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 &#39;<i>the default resource bundle should not be loaded by the VM if it is not needed</i>&#39; 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&#39;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">&lt;<a href="mailto:dmsmith@crosswire.org">dmsmith@crosswire.org</a>&gt;</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&#39;ve tried a variation of this. The only difference is that we
    don&#39;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&#39;d get the &quot;Other&quot; 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 &quot;minority&quot; 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 &quot;Other&quot; or
    &quot;Unknown&quot;?<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 &quot;lazy.&quot;<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&#39;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>&quot;<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&#39;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">&quot;</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">&lt;<a href="mailto:mjdenham@gmail.com" target="_blank">mjdenham@gmail.com</a>&gt;</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&#39;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&#39;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">&lt;<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>&gt;</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&#39;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
                          &lt;<a href="mailto:mjdenham@gmail.com" target="_blank">mjdenham@gmail.com</a>&gt;
                          wrote:<br>
                          <br>
                          &gt; I have occasionally tried to improve the
                          slow start-up times of And Bible &amp; JSword
                          without much success.  However, one area which
                          I have a suspicion may take time is property
                          file loading.<br>
                          &gt;<br>
                          &gt; 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>
                          &gt;<br>
                          &gt; What do you think?<br>
                          &gt;<br>
                          &gt; Regards<br>
                          &gt; Martin<br>
                          &gt;<br>
                        </div>
                      </div>
                      <div>
                        <div>&gt;
                          _______________________________________________<br>
                          &gt; jsword-devel mailing list<br>
                          &gt; <a href="mailto:jsword-devel@crosswire.org" target="_blank">jsword-devel@crosswire.org</a><br>
                          &gt; <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>