[Mono-devel-list] String constants and localization

Andreas Nahr ClassDevelopment at A-SoftTech.com
Tue Jul 15 02:53:27 EDT 2003

> > The absolute minimum size you can archive (removing all strings, assumed
> > 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
> > itself)
> > MS Compact: about 40KB
> > Suggestion: about 40KB (assuming you remove the enumeration after
> 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
> > itself)
> > MS Compact: about 1040KB
> > Suggestion: about 1290KB (assuming the enumeration entry is average 1/4
> > 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
> > (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

More information about the Mono-devel-list mailing list