[Mono-devel-list] How to handle huge string collation resources?

[Atsushi Eno]

Hey,

Ben Maurer wrote:
> On Wed, 2005-06-22 at 04:26 +0900, Atsushi Eno wrote:
>> 	3. run "make". It will automatically downloads some files
>> 	   from some sites. For now without this step the build
>> 	   b0rks.
> 
> Of course, this will need to be changed ;-).

duh ;-)  It will be checked in when we decide how to handle it.

>> Here is a serious problem. In step 3 it makes 1.2MB of a C#
>> source file that results in 500KB increase of mscorlib.dll.
> 
> If you are generating a file in C#, you are going to be managing memory
> badly. C# has no sense of a const array. When you say:
> 
> static readonly int [] x = {
> 	...
> }
> 
> This array is actually allocated in the GC *at runtime*.
> 
> Doing it in a header file would be an option. Not really ideal because
> it gets into our package three times (once for the statically linked
> mono binary, another for libmono.so, another for libmono.a).
> 
> The best option is to have it as a resource in a dll. The runtime memory
> maps that.

Oh, I didn't know that resources are mmapped. Yeah, then that
sounds the best way.

BTW doesn't that mean all that kind of culture resources had better
become managed resources, unless they are required at runtime?
We also have huge culture-info-table.h and char-conversions.h
in metadata.

>> And for about 200KB of data, they are just for CJK cultures
>> so they won't be used unless we use those cultures to handle
>> culture-sensitive CJK collation. That is mostly waste of memory.
> 
> Not if the data doesn't get paged in ;-).

> The memory system essentially does that via the mmap call, however it is
> hidden from view.

Well, they will be hidden from view, but don't they still eat
memory when mscorlib.dll is loaded? Don't they still get paged?

Atsushi Eno