[Mono-devel-list] [PATCH] Reworked unified Locale classes

[Kornél Pál]

> From: Ben Maurer
> Benchmarks really don't matter here I think. The *only* reason people
> would use the Locale class is when an exception gets thrown and we need
> to get the error message. Since an exception is 1) exceptional and 2)
> already slow, not too much harm in slowing it down more :-).

OK.:)

> So, we should go for the simplest design. I think the simplest one was
> the one using ThreadStatic.

I think a lock on the resource manager is better as it requires no thread
variables and it is locked anyway so it does not degrade performance.

> if (inside_gettext)
>    // don't do anything
>    return msg;

Because as you mentioned this can occur only when getting message for
exceptions furthermore only when the exception occurs in ResouceManager or
classes it uses it's better to append "GetText recursion: " as the exception
message is for informational purposes.

> try {
>    inside_gettext = true;

Neither lock nor using is generated in this way either by CSC or MCS. They
all create object or acrique lock outside the protected block so I think the
current code is correct.

>    return ...
> } catch {
>    inside_gettext = false;
> }

It's better to use finally.

> From: Peter Dennis Bartok
> Ben, you are not correct. In MWF, the Locale class is used for getting
> localized text for buttons in dialogs, for retrieving built-in images (for
> dialogs), icons and cursors, and to retrieve the category and description
> for viewing properties in propertygrid. Those are not in the main code
> path
> and don't demand ultra-high speed, but performance does matter a bit

You can make sure that it will cause no more performance overhead as it
currently does because MWF is already using ResourceManager for images. And
of course this synchronization is only for corlib and GetText.

> From: Ben Maurer
> Anyways, I am sure that localization is going to incur some overhead for
> non-english cultures. For english, we should strive to make the overhead
> near 0.

Localization allways cause some overhead but just look at MS.NET it is
localized, it has it's English resouces in resouce files as well and I think
it has good performance.

I think the best solution is to do what I have done: using a custom
ResouceSet that returns the identifiers in GetString methods because
ResourceManager falls back to parent cultures. Furthermore if there are no
invariant resources it will throw MissingManifestResourceException. And
because ResouceManager select the appropriate ResouceSet using it's own
logic it we add some logic for English in GetText then it will degrade the
performace when using any other languages.

Kornél