>>>>> "Brad" == Brad Giaccio <[EMAIL PROTECTED]> writes:
Brad> Don't worry you are not being dim. First your assuming a well
Brad> constructed VM when speaking of a string cache, and I've seen
Brad> no evidence that sun or blackdown by extension has implemented
Brad> such a beast.
No, Im not (just) talking about a well constructed VM. From
the 1.0 Java language spec
Spec> Each string literal is a reference (�4.3) to an instance
Spec> (�4.3.1, �12.5) of class String (�4.3.3, �20.12). String
Spec> objects have a constant value. String literals-or, more
Spec> generally, strings that are the values of constant expressions
Spec> (�15.27)-are "interned" so as to share unique instances, using
Spec> the method String.intern (�20.12.47).
Hence in java
"String" == "String" is guaranteed to return true whilst
new String( "String" ) == new String( "String" )
will return false.
Either of these using the equals method will of course
return true.
In other words if the VM does not implement this string
flyweight cache it is in violation of the language spec. If you want
to see evidence of this its in the String.intern() method. As this is
native its not very informative, but there you go....
Brad> But I won't quible over a one string object.
Brad> Although a better choice would be to use String quote = "\"";
Brad> String escape = "\\"; That way you are assured that the string
Brad> regardless of its creation means, is only allocated once.
Brad> But lets examine these two methods valueOf contains one if
Brad> construct getChars contains three if's then an arrayCopy
Brad> arrayCopy is native code so all bets are of on its efficiency,
Brad> consindering that code is probablly doing the same boundary
Brad> checks we just performed
It does indeed perform those checks. It throws a different
exception hence the duplication. I would probably have coded this
myself by catching the exception from System.arraycopy, figuring out
(with if statements) after the fact why it had occurred, and either
rethrowing the exception or making a new one of the correct type. Much
slower if the exception is thrown (because of two potential object
creations), but this should be in, well exceptional cases right?
Brad> On the other hand the append(char) contains one if, and array
Brad> index and an increment
Brad> so append(str) contains 6 if statements to append(str)'s 1
All true, all true. Although the if statements are integer
comparisons so probably fairly fast.
Adding a two long char array (initialised once) would be
quicker still though, as there would be only one method
invocation. Assuming you used a static char array, which is the same
argument as for the String flyweight cache.
Still its at this point that I reach for my Donald Knuth
saying (I think it was Knuth). "Premature optimisation is the root of
all evil" (bad paraphrase). At this stage we have no ideas that the
differences we are talking about are going to be in anyway significant
in the end app. I tend to favour the "write code clearly and
obviously, if slowly at first, and then optimise if you really have to"
school of thought on this one....
Cheers
Phil
