[Mono-devel-list] String constants and localization

[Andreas Nahr]

> > The absolute minimum size you can archive (removing all strings, assumed
1MB
> > strings without changing the code base):
> > Mono: 1000KB (cannot remove without removing every single string)
> > MS: estimated 250KB (assuming the identifier is average 1/4 of the
string
> > itself)
> > MS Compact: about 40KB
> > Suggestion: about 40KB (assuming you remove the enumeration after
compiling)
>
> We can not remove the enumeration after compiling, as I said before, you
> can always do:
>
> object a = MyEnum.Value;
>
> And given the compiler structure, it is a lot easier to implement what I
> described before than removing an enum after it has bene used.

As I said before: I do not want to change *anything* in the compiler. Just
remove the code after compiling. If someone uses
object a = MyEnum.Value;
He will get a typeload exception or something like that.
Also you can just leave the thing in (You definatelly would do that for
desktop systems) which would bring the whole thing up to 175KB, which still
is a lot less than 1000KB

> > The minimum size you can archive when using localization (one localized
> > resource set, assumed 1MB strings):
> > Mono: 3000KB
> > MS: estimated 1500KB (assuming the identifier is average 1/4 of the
string
> > itself)
> > MS Compact: about 1040KB
> > Suggestion: about 1290KB (assuming the enumeration entry is average 1/4
of
> > the string itself) (assuming you remove the enumeration after compiling)
> > Suggestion: about 1040KB (assuming you remove the enumeration after
> > compiling)
>
> Not quite correct.  Mono would include 1M of strings that are already in
> one language (english or as I suggested previously, anyone of your
> liking).
>

Please don't forget one thing: In .Net you can set the language *PER
THREAD*. I don't see a chance to replace the hardcoded string with that.
Also replacing all hardcoded strings will probably make the code much harder
to maintain.
It is true that for a solution where you are not doing any localization simp
ly including the strings into the assembly produces an optimum result
(disregarding the loss that comes with encoding)

> > RAM need at runtime when using localization for getting ONE/The first
entry
> > (one localized resource set, full memory cache, assumed 1MB strings):
> > Mono: 2000KB (Hashtable implementation)
>
> Wrong.

I wrote above : *full memory cache* - under this circumstance it is *true*

> As I repeated a number of times: you do *not* need to use a Hashtable.
> In fact, Microsoft .NET does *not* use a Hashtable, they use an
> "internal" method that maps strings to their index, using a binary
> search.

MS *does* load *everything* into memory at the first access of the first
string. So they are using a binary search *in memory*

As I wrote in the last post if you load it directly from HDD you can easily
get situations with thousands of HDD/ Network Seeks+Reads per second - if
your HDD is fast enough to deliver that in a second ;)

> > Mono would use the most memory of all implementations (For the compiled
> > assembly as well as RAM for execution)
>
> It would use the most memory if you *insist* on the hashtable
> implementation, as opposed to the binary-search implementation.

It would use most memory in *every* scenario except the one where no
localization takes place at all

> If you do the *right* thing (as I pointed out before), the memory use is
> minimal, and does not even show up.

I'm wondering if this solution with directly performing a binary search on
HDD would work then why MS decided to load the whole thing into memory.

This are some timings I did with the sample implementation:
Tests on a 2.0 GHz Athlon with a new 7200rpm IDE HDD:
Access to a single localized string with suggestion: about 0,001 ms
Access to a single localized string from HDD with binary search: about 1,2ms