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

[Ben Maurer]

On Thu, 2005-06-23 at 12:41 +0900, Atsushi Eno wrote:
> Ben Maurer wrote:
> >> 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.

They are in C, where they are a const array. One advantage of having
them there is that we don't have to do conversions for different endian
systems.

> 
> >> 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?

Memory in a mapped file that is never touched never gets read from the
disk, nor is physical memory allocated for it.

-- Ben