String/ object creation/ efficiency

[mac]

Suppose you have some code that looks like this

	StringBuilder str = new StringBuilder();
		
		str.append("one");
		str.append("two");
		
		System.out.println(str.toString() + "three");
		System.out.println(str.toString() + "four");
		System.out.println(str.toString() + "five");

Question 1: In this example, str.toString() conversions happens 3 times separately, or Java knows to reuse the results of conversion done once locally?

Question 2. Would any efficiencies be introduced by changing the code to

		StringBuilder str = new StringBuilder();
		
		str.append("one");
		str.append("two");
		
		String x = str.toString();
		
		System.out.println(x + "three");
		System.out.println(x + "four");
		System.out.println(x + "five");

Please let me know

[Norm]

There is a compiler option that will show you the code that is generated. If you want to know what the compiler is generating look at that.

Calling toString() once should be more efficient. See above

[DarrylBurke]

In the first code, str.toString() will be executed 3 times. The compiler cannot cache the return value -- what happens if str is modified by another thread between calls?

db

[JosAH]

In the first code, str.toString() will be executed 3 times. The compiler cannot cache the return value -- what happens if str is modified by another thread between calls?

Well, if that str is just a local variable no other threads can touch it so theoretically (if the compiler were that smart) those three toString( ... ) could've been collapsed to just one; but then again: the compiler doesn't know that the toString() method is referential transparent so it duly generates three method calls ...

kind regards,

Jos

[DarrylBurke]

Well, if that str is just a local variable no other threads can touch it so theoretically (if the compiler were that smart) those three toString( ... ) could've been collapsed to just one; but then again: the compiler doesn't know that the toString() method is referential transparent so it duly generates three method calls ...

kind regards,

Jos

Thanks Jos, but does the compiler really look to see that the local variable has in fact been locally assigned to refer to a new object, and not to some existing StringBuilder that might be referred to -- and modified via -- another variable elsewhere?

db

[JosAH]

Thanks Jos, but does the compiler really look to see that the local variable has in fact been locally assigned to refer to a new object, and not to some existing StringBuilder that might be referred to -- and modified via -- another variable elsewhere?

AFAIK the javac compiler is far too nearsighted to check anything like that, i.e. it simply generates the dumb code and doesn't analyze anything; it isn't much of an optimizing compiler. Partly that's because it doesn't know, and can't know anything about, say, referential transparency of methods, i.e. as far as javac is concerned the StringBuilder constructor might start a new Thread that modifies the StringBuilder (therefore forcing three times the toString() method call code to be generated).

kind regards,

Jos