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
