On 15 October 2010 15:00, Ben Kloosterman <[email protected]> wrote:
> > >> > >> 2. The problem we are trying to solve ( GC , O(N) ) apply only to > >large > >> strings so why pay the price for frequently used small strings. A > >horses for > >> courses approach may fit better and the big string can solve a number > >of > >> other problems. > > > >Since *any* reference takes 8 bytes (the size of a pointer) I don't > >see an empty string taking 8 bytes as an issue. > > Empty string wont be 8 bytes you are looking at the reference to string > > + the object overhead + 2 internal null pointers for an increase of 16 bytes.. > > Even worse when not using null able references you would have a string array > initialized to empty strings this could be nasty for a multi dimensional > array ( eg data tables , sql readers etc) . Anyway empty arrays by > themselves are not a huge issue but small strings in general especially as > they are very frequent. Since strings are immutable and all empty strings are the same you can always reference the *same* empty string. Short strings sure will have some overhead but they do in any language which uses scalable representation of strings and it does not seem to be a huge problem. Also since you are presenting and *interface* you can optimize cases which turn out to be problematic later. One of rather straightforward optimizations may be to represent strings which aren't split into multiple parts by a simpler object. Thanks Michal _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
