From: Paul Rohr (paul@abisource.com)
Date: Mon Apr 29 2002 - 18:37:26 EDT
At 05:45 PM 4/29/02 -0400, Dom Lachowicz wrote:
>> - speed ... ID lookups should be faster than atomized string keys
>
>We'll still do ID lookups.
I know. That's what I like most about your proposal.
>I plan on keeping the integer IDs around and
>keep our exposed XAP_StringSet exposed interface just about (if not)
>100% intact. I do plan on making some additions to convert strings
>transparently into some given locale via getString(). I plan to make a
>map of integer id->en_us string. gettext provides the en_us
>string->xx_yy string map for us, including intelligent fallbacks (which
>our current stringsets don't handle). With those 2 tidbits of data, you
>can see how I can trivially make a map of integer id->xx_yy string,
>which is what we have currently.
Sure. All I meant was that it's faster to do the current mapping:
ID --> xx-YY string
The new pathway will have a few more steps:
ID --> en-US string --> atom/hash --> xx-YY string
The latter two steps happen inside gettext, of course.
>Now if I preload those strings on
>application startup (XAP_App or AP_App initialization), we now have
>exactly the same situation as with the XML strings.
Yep. The net effect is the same.
Or were you thinking of caching away the first step in the mapping, and
reducing it down to something like this?
ID --> atom/hash --> xx-YY string
Or even this?
ID --> xx-YY string
(These two might require extra APIs into gettext.)
bottom line
-----------
Off the cuff I can't think of any speed-critical places where the slower
string lookup should have a user-visible impact. What's the worst-case
scenario? A big dialog needs lots of strings localized before we can load
it. I doubt the mapping would be *that* slow.
As you suggest, for a slight on-launch penalty you could optimize out all of
gettext and work from a blazingly-fast in-memory cache. As if GUI string
lookups were a performance problem for us. Hah! :-)
Paul
This archive was generated by hypermail 2.1.4 : Mon Apr 29 2002 - 18:38:22 EDT