<!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 &inBuf) {
...
if ((size > 0) && cacheBuf && ((unsigned)start < cacheBufSize)) {
//TODO: optimize this, remove strlen
...
:)
New numbers with all filters and functionality in place:
[scribe@laptop cmdline]$ time ./outplain KJV > /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"><scribe@crosswire.org></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 => 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>