> >> > I have a commerical application that has run fine under
> >> > all 3.x version of PalmOS. Under 4.0 it runs very slowly.
> >> > I have not been able to pinpoint any particular API calls
> >> > that run slower. It appears as if the C code just runs
> >> > slower especially string manipulation and searching.
> >> > Anyone had a similar experience?
> >> >
> >>
> >>I think you'll find that StrCompare() and StrNCompare() are slower in the
> >>4.0 SDK.
Actually it's the 4.0 ROMs - the SDK has nothing to do with it.
> >StrCompare should be roughly comparable in speed, less the trap
> >dispatch overhead of calling through to TxtCompare.
> >
> >StrNCompare will be slower in 4.0 - the longer the strings you're
> >passing in, the bigger the performance issue.
>
>Somebody (perhaps the "pedit guy") did actual timing comparisons
>and found Str[N]Compare was substantially slower on 4.0 than
>on previous releases.
StrNCompare (not StrCompare) is substantially slower on 4.0 if you
pass in long strings.
>The reason was the call to TxtCompare, which
>uses multi-byte-based comparisons.
No, the reason was that StrNCompare now calls StrLen() on both
arguments. TxtCompare does a quick check to see if the device's
character encoding is simple single-byte, and if so it uses the same
fast byte-indexed sort value table method as in previous versions of
the OS. The only time you should see a significant speed difference
between pre-4.0 and 4.0 is if you're comparing two strings which are
weakly equal at the primary sort level (e.g. "resume" and "r�sum�"),
in which case there's an extra comparison loop.
To verify this, I ran some timing tests. The cases I tried (from most
likely to least likely) were:
a. Strings differ at first character ("This is a string" vs. "I have
a string").
b. Strings match exactly ("This is a string" vs. "This is a string").
c. Strings differ at secondary sort level ("This is a string" vs.
"this is a string").
The number of ticks for 10000 calls to StrCompare were:
a b c
3.5 71 202 72
4.0 110 352 821 Using StrCompare
4.0 84 327 795 Using TxtCompare
So for case (a), 10000 calls to TxtCompare on 4.0 will take an extra
.13 seconds longer than calling the same number of calls to
StrCompare on 3.5.
For case (b), the delta will depend a bit on how long the two strings
are, but having lots of strings that exactly match isn't very common.
Case (c) is the interesting one. 4.0 takes longer because it
implements a three pass sort. If the two strings are equal at the
primary sort level, then it does another comparison loop to see if
they differ at the secondary sort level (caseless comparison). If
they still match, then it backs off to the tertiary sort level, which
does an accentless and case-insensitive comparison. So the times wind
up being much longer, but this situation rarely occurs in real life.
>If you don't need the muti-byte string support, then you can use
>the Str[N]CompareAscii functions.
No, no, and no (please). This isn't a multi-byte vs. single-byte
issue. You should only use Str[N]CompareAscii if the results of the
strings you're comparing are _not_ displayed to the end user.
I almost didn't make these routines public, because I had precisely
this concern about developers using them when they should be using
Str[N]Compare or TxtCompare.
Str[N]CompareAscii compares raw byte values, and thus can be used to
sort any string that's null-terminated, including double-byte encoded
text or pseudo-random number sequences converted to Base64 or
whatever, as long as you don't care about the specific ordering of
the results.
-- Ken
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
