[Mono-dev] Replacing/Removing I18N

[Atsushi Eno]

Andreas Nahr wrote:
> And I wrote quite extensively in the original post why this is something 
> that we definatelly wouldn't want to have.

s:/we/I/;

> Why would embedding them into corelib be a waste of resources? As far as I 
> found out this approach should use the minimum amount of resources possible.
> It surely uses a LOT less resources than having approx. 150 additional 
> assemblies that each contain substantial overhead. And it is faster in 
> loading than external assemblies.

"Why" ? mscorlib.dll is mandatory. About 99% of Encoding classes are
optional for a user. If you split CJK data out (it should be done),
then ALL of those data are extraneous for CJK people like me.
ISO-8859-1 is already part of mscorlib (by design) so it already does
not require additional loading.

> I don't know if mono mmaps external resource files. If it does not then 
> putting the files into external files (like *.nlp) would be a HUGE waste of 
> memory resources. If these files are cross-process memory-mapped then it is 
> just a matter of taste if we want to have 150 externally linked files or 
> have them embedded (in fact then we could even mix both possibilities 
> without any additional work needed).

I quite don't understand why you speak about the _existence_
of mmaped external resource loader. Well, I might be wrong; assembly
loading might be so special and mmaped loading hack might be simply
impossible for external resources. Plus, mandatory/optional resource
loading differ as I wrote above.

It is not just a matter of taste. Those resources don't have to walk the
same road as managed assemblies do.

More importantly, it won't be easily done to use those blocks of arrays
for conversion and keep conversion performance than IL-based
switch-cases (there certainly is a reason why Portable.NET guys
implemented encodings in that way). Such changes will become a
significant trade than just the taste of resource loading. And I for
sure prefer existing code. Uncertain memory consumption reduction by
situation and certain Encoding.GetBytes() slowdown do not sound good to me.

Ok, ok, I might be wrong here again, so let's talk about it after you
have done with it.

Atsushi Eno