<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Troy,<br>
Looks promising. I will test it out tonight. Thanks for looking into
that Troy. <br>
--<br>
In Christ,<br>
David Trotz<br>
<br>
<br>
Troy A. Griffitts wrote:
<blockquote cite="mid:4885BCE0.9060307@crosswire.org" type="cite">
  <pre wrap="">Hey Karl,

Yeah, it might be nice to have such a utility, but I think I fixed it.

Found this line:

in:
void zVerse::zReadText(char testmt, long start, unsigned short size, 
SWBuf &amp;inBuf) {
...
      if ((size &gt; 0) &amp;&amp; cacheBuf &amp;&amp; ((unsigned)start &lt; cacheBufSize)) { 
  //TODO: optimize this, remove strlen

...

:)

New numbers with all filters and functionality in place:

[scribe@laptop cmdline]$ time ./outplain KJV &gt; /dev/null
Real        0m8.732s
user        0m8.034s
sys        0m0.578s

[scribe@laptop cmdline]$ time ./search KJV "God love world"
[0=================================50===============================100]
  ======================================================================
John 3:16
James 2:5
I John 3:1
I John 3:17
I John 4:1
I John 4:9

real        0m3.006s
user        0m2.283s
sys        0m0.572s

I'm very happy with those numbers.  Let's see if we can get svn to 
compile on a mobile platform and see how we do for small devices.

        -Troy.



Karl Kleinpaste wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">"Troy A. Griffitts" <a class="moz-txt-link-rfc2396E" href="mailto:scribe@crosswire.org">&lt;scribe@crosswire.org&gt;</a> writes:
    </pre>
    <blockquote type="cite">
      <pre wrap="">The difference between iterating the KJV 
(heavily tagged OSIS zText) and GerLut (reasonably tagged GBF RawText) 
without filters involved, was about 5x speed difference (12.9s vs. 2.7s).
      </pre>
    </blockquote>
    <pre wrap="">I have wondered now and again about a utility which would do a one-time
decompress with a requisite update of .conf, after the fashion of
mkfastmod (that is to say, as a distinct step of maintaining one's
modules), just to step past the "compressed module =&gt; slow performance"
problem entirely.

I understand the need for compressed support for the sake of reduced
download times as well as not being wasteful for folks on space-limited
platforms.  But for those of us using modern systems where monster discs
have become routine, disc space costs nothing, and the performance
trade-off is obvious.

_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
    </pre>
  </blockquote>
  <pre wrap=""><!---->

_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
  </pre>
</blockquote>
<br>
</body>
</html>