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

Atsushi Eno atsushi at ximian.com
Thu Jun 23 03:10:33 EDT 2005


Hi,

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

They are not only 200KB tables (that number is just for CJK
support which is rarely required) but about 500KB as a whole.

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

Well, I need more clarification for them.

- For standard collation support (numbers are in length):
  - byte[] : 153360.
  - int[] : 13552.
  - some extent of additional byte[] : maybe less than 5000
- for CJK support which is rarely used:
  - ushort[] : 20000 * 3 + 30000
  - byte[] : 20000
- for String.Normalize() which is only for .NET 2.0:
  - byte[] : 30000
  - int[] : 2700
  - short[] : 17600
  - maybe additional int[] : 4000

So, they are mostly byte for collation, except for CJK support
which is not referenced unless we use CompareInfo methods from
CJK cultures. So I think managed resources won't be bad here.

For String Normalization related stuff, I still think it would be
better to have them in mscorlib.dll since they are unused in the
default profile.

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

I agree.

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

Ok, then right now I need to hack on corlib Makefile to run make
under Mono.Globalization.Unicode.

Atsushi Eno



More information about the Mono-devel-list mailing list