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

[Ben Maurer]

On Thu, 2005-06-23 at 01:05 -0400, Miguel de Icaza wrote:
> Hello,
> 
> > > 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.
> 
> Cant the same be said about the table that Atsushi is creating?  Do we
> really worry about the 200k replicated between Mono and libmono.so.

Not too much ;-). Well, it might make a difference if on the same box
somebody is using mono and libmono.so -- but not a big issue.

I've no idea what kind of data is in the table, and if it is endian
dependent. If it's just a byte array, we'd be fine...

> The resource approach has also the downside that access to it would be
> through the Stream interface (even if mmapped) while getting a pointer
> to a C-statically defined array would allow the corlib code to access it
> without any wrapper code.

Well, since we are in corlib, we can get the void* ;-).


Anyways, I think the two approaches don't make much difference in terms
of performance (except possibly the endian stuff). Where there is a
difference is in terms of development model:

If we want to include the stuff in the C runtime, we pretty much have to
check in the generated file to SVN. We can't run C# code before the
runtime is compiled. OTOH, if we include the stuff as a managed resource
to corlib, we could run a mono app at that point to generate the file.

While this stuff is in active development, checking in a large file to
svn is probably going to make mono-patches-list a bit annoying.

So maybe the best plan would be a managed resource for now, and once the
table is stable, moving it into C if that makes a substantial
performance difference.

-- Ben