[Mono-devel-list] String constants and localization

[Miguel de Icaza]

Hello!

> I've read your answer, but it seems that at quite some points you overlooked
> advantages (maybe I'm also wrong with any of these, but I don't think so).
> So I added some addidional comments to it

Thanks for getting back to me.

I do agree that there were various of advantages, but from a maintenance
point of view, I did not get the feeling that those improvements were
enough to justify the design change.  This is purely my personal
feeling, so we should definitely continue exploring this topic.

That being said, one of the successful policies we used in Gnumeric was
that we aimed for maintainability, completeness and only in a third
place about performance and memory consumption.  

This allowed us to focus on getting things done right, and getting the
basic infrastructure in place.  And only later we did performance and
memory improvements.  This turned out to be good, because most
ahead-of-time optimizations turn out to be wrong.

Let me give you an example.  In the C# compiler I was very worried that
using the various "Cast" classes was going to be very slow, and I
decided that one day, I would rewrite the whole cast system to avoid
these objects.

Well, turns out that in the execution time profiles and in the memory
profiles, these do not even show up.  So we are able to keep the elegant
design, and profiling showed that the issues were elsewhere: in
unsuspected places.

So, anyways, after getting the philosophical bits out of the way, lets
get to the meat of it:

> * Much faster
> * Much smaller Assembly size (see below)
> * Much smaller RAM need

These are the items that we can measure, and we will have to balance
with the proposed changes, and the maintainance issues.

> * More safe when programing because of compile errors for e.g. typos

There are already tools in place to cope with this things.  For example,
we can use gettext to pull the strings out, so this is actually an
automated process, and one that existing translatros are familiar with.

The enumeration approach on the other hand, opens the doors to new
problems in the build system and on the setup;  Maybe not terribly hard
to fix, but they add to the plate.

> OK - but IMHO your solution just has two flaws:
> * Reimplement the chunks we already have for handling resources
>    in corlib to cope with all the CultureInfo bits (which is exactly what
> you wanted to avoid above)

This piece is left intact.  The only change is that we have to expose an
internal method that will perform the string -> index mapping in the
ResourceReader without using the Enumerator-based API.

This is fairly simple to do (and is in fact, what Microsoft does).

> * Sooner or later you will always come to the GetResourceStream function,
> which actually provides a memory stream, which is: loading all things into
> memory (and if you want to provide a complete second infrastructure for
> strings, then the work that has to be done would be IMHO FAR more work than
> anything you might have to do to implement something like my suggested
> solution)

Well, we do not need to make GetResourceStream load everything into
memory;  In fact, if this is the case today, it sounds like we should
optimize that process as well.

> Sorry but IMHO this it total overkill. You want to perform a binary search
> DIRECTLY on a file containing an estimated 200KB string values EVERY time we
> do a string lookup. Are you sure this won't totally fry your HDD. And what
> about if the assembly we are accessing is on e.g. a network share that has
> slow access times?

It works fine enough for Monodoc, I can really not tell the difference
of disk access.  Now, lets assume we have 8k strings, that turns out to
be 12 different seeks+reads, and for the later cases, they will probably
hit the cache.  

Gettext works like this today, and there are no complaints about fully
localized systems today about the speed.  And keep in mind that with
gettext, every app on the system is doing this process all the time.

Anyways, the summary is that I do not think that deviating today from
the .NET framework setup is worth it.

Miguel.