Hi, > Please observe: > > 1. > the amount of memory needed to manage the allocation > is greater than the number of bytes > needed to store one additional character, > so the relative impact on memory usage will not be dramatic.
This is just ridiculous. An average Java app has tons of Strings in them, most of which are _not_ used in GetStringChars. Allocating one additional jchar for each String surely _does_ impact. Especially on embedded systems (this is where I'm working on). > 2. The string usually has much more characters then one. > That means, if strings take 10 characters on the average, > the overhead is 10%, in the impossible worst case, as explained below. > This is an overhead I (and most programmers) can live with. Yeah, but not in the embedded/mobile world. > 3. Memory is allocated in chunks. > The size and alignment of the chunk is subject to various limitations. > If the characters of the string do not fill the chunk entirely, > there is good chance > that there will space for the terminating zero anyway. Yeah, and if not? I can only speak for Jamaica, where memory is allocated in chunks of 32 bytes, or 16 chars. There's a 1 out 16 (actually, 2 out of 16 because of some internal stuff) chance that there's no trailing space for the zero, so should we allocate another 32bytes, only to get this zero termination for a JNI method that's only rarely used? So much for the no-impact statement above... Cheers, Roman -- http://kennke.org/blog/
