The mechanism assumes that basically all translation files are loaded so a
match is found quickly. There probably should be an early return if there
are no translations (as is the case with trunk images, I think?).

- Vanessa -

On Wed, Oct 28, 2020 at 1:53 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi Eliot.
>
> Hmm... in 2010 there was a change in String >> #translated to also include
> some kind of domain knowledge based on "thisContext sender method". (I
> suppose it got merged with all Etoys changes in Squeak 5.1).
>
> ['world' translated] bench.
> ---NO DOMAIN LOOKUP --- '847,000 per second. 1.18 microseconds per run.
> 3.69926 % GC time.'
> ---DO DOMAIN LOOKUP  --- '9,190 per second. 109 microseconds per run.
> 3.57928 % GC time.'
>
> Given that there are 1558 senders in a Trunk image, this might be worth
> improving. :-)
>
> I propose to change #translatedInAllDomains, which is kind of a "detect"
> looking desperately for some translation that has not the given form....
> enumerating all package names along the way to be used as domain names.
>
> Domain names are for GetText support. Each .mo file can represent a
> different domain. Such a modular separation helps external tools (and
> humans) to better browse and understand the kind of translation that is
> needed. It's rather common practice, I suppose.
>
> Maybe we should just support a wildcard '*' as valid domain name and then
> let the GetTextTranslator figure out how to enumerate all the accessible
> .mo files?
>
> String >> translatedInAllDomains
> ^self translatedTo: LocaleID current inDomain: '*'
>
> ['world' translated] bench.
> ---WILDCARD---  '408,000 per second. 2.45 microseconds per run. 1.55938 %
> GC time.'
>
> Now somebody has to change GetTextTranslator. I hope it does not break any
> generic GetText support to enumerate all .mo files in a locale directory.
>
> Best,
> Marcel
>
> Am 28.10.2020 06:59:07 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
> Hi All,
>
>     I have occasion to simulate the simulator (chancing down a context
> manipulation bug).  In doing so I notice that there seems to be some awful
> ) N^2 behaviour in doing things as straight-forward as setting up the world
> menu.  Here's a back trace from the simulator of a current trunk image:
>
>   16r3061C8 M Dictionary>associationsDo: 16r16BC028: a(n) Dictionary
>   16r306200 M Dictionary>keysDo: 16r16BC028: a(n) Dictionary
>   16r306238 M [] in Dictionary>keys 16r16BC028: a(n) Dictionary
>   16r306280 M Array class(SequenceableCollection
> class)>new:streamContents: 16r16FA068: a(n) Array class
>   16r3062C0 M Dictionary>keys 16r16BC028: a(n) Dictionary
>   16r3062F0 M PackageOrganizer>packageNames 16r1540BE8: a(n)
> PackageOrganizer
>   16r306320 M TextDomainManager class>allKnownDomains 16r188A848: a(n)
> TextDomainManager class
>   16r306358 M ByteString(String)>translatedInAllDomains 16r3479FF8: a(n)
> ByteString
>   16r306390 M ByteString(String)>translated 16r3479FF8: a(n) ByteString
>   16r3063D8 M [] in TheWorldMenu>fillIn:from: 16r3C93C0: a(n) TheWorldMenu
>   16r303F38 M Array(SequenceableCollection)>do: 16rB681C8: a(n) Array
>   16r303F70 M TheWorldMenu>fillIn:from: 16r3C93C0: a(n) TheWorldMenu
>   16r303FC0 I TheWorldMenu>addSaveAndQuit: 16r3C93C0: a(n) TheWorldMenu
>
> I.e. for every item in the world menu we are enumerating over all
> packages.  Shurely shome mistake, hic!, ed.
> _,,,^..^,,,_
> best, Eliot
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201028/a406613e/attachment.html>