[Mono-devel-list] How to handle huge string collation resources?
atsushi at ximian.com
Thu Jun 23 03:10:33 EDT 2005
>> 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
> 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.
Ok, then right now I need to hack on corlib Makefile to run make
More information about the Mono-devel-list