image startup complications

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

image startup complications

timrowledge
One of the things that running Squeak in the vm simulator will teach you is that we have a lot of stuff going on during system startup. A slow startup might not seem like a big deal when you’re running on a fast machine (because it will be less-slow, duh) or planning to keep running for a while. However, on a slow machine (Pi, for example) or when you are trying to quickly spin up a wotsit for Docker (or other fashionable SaaS thingummy) the slowness can be a real annoyance.

As an example, I’ve just fired up an image under the vm sim to test a new CPIC design. After a lot of whirring you tend to get worried that something is recursively recursing and otherwise going around and around chasing its own tail recursion. So you interrupt to see where things are and … oh, yeah, going around and around in something to do with X. Proceed, wait a while, look again.. same stuff…

In this case it prompted me to look at MenuIcon initializeTranslations. What happens here is that the class MenuIcons is running down all the registered menu item icons to translate the attached strings. This involves a great deal of work to find the correct domain(s) to do the translating, potentially reading many files to build dictionaries etc. I have to do much the same in Scratch - and indeed probably ought to rework that to use the latest stuff.

Part of the job here is to find the translator for the current locale. See NaturalLanguageTranslator class>availableForLocaleID: where we check the list of known translators and if nothing is found, check for the parent of the requested locale, and if still nothing return a default. The problem is that finding the parent involves a long search which seems to mainly return a locale the same as the not-found one which of course is itself not found. So then we find the default - which involves making a new translator and going via that same long search.

Because this newly made default translator is not saved we go through this for every single string that wants a translation. I tallied the work and on a Pi with Cog VM it takes 373mS - 1/3rd of a second each time we start an image. On my iMac it’s only 37mS, which may seem too trivial to worry about but remember this is only one of many startup operations.

So, what to do? Well simply saving the new default translator back into the list of known translators - which I really suspect is what the original authors intended to do since it’s such an obvious thing - the time is cut to less than 1/5th, or 62mS. Since I’m not at all expert in the workings of the translation code I don’t want to just commit this.

It really is a trivial change-
NaturalLanguageTranslator class>>#availableForLocaleID:
availableForLocaleID: localeID
        "Answer available locale ID.
        If translator is not found for correct locale ID, then isoLanguage is
        attempted for the key."
        ^ self translators
                at: localeID
                ifAbsent: [localeID hasParent
                                ifTrue: [self translators
                                                at: localeID parent
                                                ifAbsent: [self translators at: localeID put: self default]]
                                ifFalse: [self translators at: localeID put: self default]]

There’s a *lot* of senders of #translated that this will give a little boost to.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
All computers run at the same speed...with the power off.