> Such servlets are, to paraphrase your previous posting, "horribly
> programmed." When used properly, immutable ("Pseudo-functional")
> classes like String can increase performance, rather than decrease it.
> You just have to know when it's more appropriate to use a StringBuffer,
> or a char array, or a byte array. Java provides several tools, and you
> have to choose judiciously.
that's true to an extent.
however, unicode is basically a 2x waste of space. string and
stringbuffer objects, because they embed arrays, are a 2x waste of
allocations. and usually, even if you use a stringbuffer, you wind up
needing to convert it to a string in order to call a routine that only
works with strings. most typically
while (cond) {
StringBuffer s = computeString();
System.out.println(s);
}
will still call s.toString(), another 2x waste of space.
so roughly speaking any string computation will usually involve a 4x
waste of space and a 2-4x waste of allocations over what i would achieve
writing comparable code in C++.
i think it is fair to say that java's string handling is inherently and
needlessly inefficient. certainly bad programming exacerbates this
problem.
i think it's also fair to say that the java design bears some of the
responsibility for that bad programming, because it exposes strings in a
manner that seems to lead to a lot of "horribly programmed" code.
anyway, this only bears tangentially on the memory model, so maybe we
should duke it out off the list.
david
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:22 EDT