I check some string concatenation bytecode outputs today and it looks like kotlin's internal handling of string concat is really nice, even better than explicitly using a StringBuilder with append calls.
https://gist.github.com/jrenner/e074d009614df27fd950
Is it fair to say StringBuilder is much less necessary in Kotlin?
Well, the difference between using explicit StringBuilder vs string interpolation or concatenation is that StringBuilder, being a Java class, is guarded with not-null assertions all over the place, so one can say that the compiler does a poor job handling explicit calls to StringBuilder. This is the only thing that makes concatenation/interpolation byte code better.
It is not fair to say that StringBuilder is less necessary in Kotlin: its main purpose is optimizing multiple concatenations, for example, when one conatenates strings in a loop. Without a StringBuilder such code has quadratic time complexity, which can kill your program’s performance on longer inputs.
Well, the difference between using explicit StringBuilder vs string interpolation or concatenation is that StringBuilder, being a Java class, is guarded with not-null assertions all over the place, so one can say that the compiler does a poor job handling explicit calls to StringBuilder. This is the only thing that makes concatenation/interpolation byte code better.
But all the tests except the last one are unnecessary, as you'd get an NPE anyway. The JIT surely optimizes it away, but you could reduce the bytecode size by omitting them, couldn't you?
It is not fair to say that StringBuilder is less necessary in Kotlin: its main purpose is optimizing multiple concatenations, for example, when one conatenates strings in a loop. Without a StringBuilder such code has quadratic time complexity, which can kill your program's performance on longer inputs.
Can we write something like
val sb = StringBuilder()
for (Something x : someCollection) {
sb += "$x.a $x.b ";
}
? Can we get it optimized to
sb.append(x.a).append(x.b)
rather than
sb.append(StringBuilder().append(x.a).append(x.b))
? It produces no garbage and is twice as fast, but not exactly equivalent in case of an exception, but this could be handled. Usually, sb is a local variable which can’t survive the exception anyway. In the remaining cases, shortening sb in a catch clause to it’s original length would do, right?
But all the tests except the last one are unnecessary, as you'd get an NPE anyway. The JIT surely optimizes it away, but you could reduce the bytecode size by omitting them, couldn't you?
In theory, yes, but that would require some intimate knowledge about how StringBUilder is implemented, i.e. the compiler would have to treat StringBuilder specially (setting problems of extending StringBuilders aside here).
It produces no garbage and is twice as fast, but not exactly equivalent in case of an exception, but this could be handled. Usually, sb is a local variable which can't survive the exception anyway. In the remaining cases, shortening sb in a catch clause to it's original length would do, right?
Again, in theory, this is possible. But it's clearly a microoptimization, we'd need to make sure it's worth the trouble before implementing it.
But all the tests except the last one are unnecessary, as you'd get an NPE anyway. The JIT surely optimizes it away, but you could reduce the bytecode size by omitting them, couldn't you?
In theory, yes, but that would require some intimate knowledge about how StringBUilder is implemented, i.e. the compiler would have to treat StringBuilder specially (setting problems of extending StringBuilders aside here).
I didn't mean anything StringBuilder specific, but method chaining in general, or equivalently a sequence of calls like
something = something.doSomething(…)
something = something.doSomethingElse(…)
No null check for something is needed after the first row, as the second would throw anyway.
It produces no garbage and is twice as fast, but not exactly equivalent in case of an exception, but this could be handled. Usually, sb is a local variable which can't survive the exception anyway. In the remaining cases, shortening sb in a catch clause to it's original length would do, right?
Again, in theory, this is possible. But it's clearly a microoptimization, we'd need to make sure it's worth the trouble before implementing it.
I'd bet, it's pretty important (factor two for a common operation), but I'm sure, there more important things to do now. Moreover, it's a hidden optimization which changes nothing but speed, so there's no need to hurry. Maybe the JIT does it itself, it could in theory.
I use the following method extensions to achieve method chaining
/** execute a function with this as parameter */ fun <T> T.self(f:(x:T)->Unit):T{ f(this) return this }/** execute a function with this as receiver */
fun <T> T.me(f:T.()->Unit):T{
f()
return this
}
val user = User() me {
setName(“…”)
setAge(18)
}
No null check for something is needed after the first row, as the second would throw anyway.
To guarantee this, we'd need to know that chained calls actually return "this", and not null or anythng else. Which we can't know.
To null check for something is needed after the first row, as the second would throw anyway.
To guarantee this, we'd need to know that chained calls actually return "this", and not null or anythng else. Which we can't know.
No, all you need to know is kotlin/jvm/internal/Intrinsics.checkReturnedValueIsNotNull.
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
``
DUPLDC “StringBuilder”LDC “append”INVOKESTATIC kotlin/jvm/internal/Intrinsics.checkReturnedValueIsNotNull (Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;)VLDC “c”INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;No, what I mean is that the first red line is redundant as the second would throw anyway. It's virtual call, so it has no choice if its recipient is null. Or am I missing something? The produced message, maybe?
I see what you are saying. Yes, the only difference would be produced message + predictability of the exception class. The latter might be addressed by having checkReturnedValueIsNotNull() throw NullPointerException with a nice message. Thanks for the idea, we'll think about it.
Incidentally, the assertion generation logic has been changed in the recently released M9, and currently the behavior is exactly as you suggest (assertions are gone from some otehr places too), but as we are planning on putting some assertions back, this is not final yet.
while I’m searching for the difference between using StringBuilder and Kotlin string concatenation, this thread showed up. I don’t know if newest kotlin versions do the optimization for the strings concatenation … but from @abreslav answer I think it doesn’t so I made an operator overloading for the plus operator so I could write something like this
var stringBuilder = StringBuilder()
stringBuilder += “Hello”
stringBuilder += “Worled”
and this is the extension function for the overloaded operator.
operator fun StringBuilder.plus(string:String):StringBuilder = this.append(string).append("\n")
So maybe if there is no choice for the compiler to do the StringBuilder job, a little extensions in the standard library make code a little nicer
The discussion above is not about the compile not using the StringBuilder for concatenation.
In Kotlin, string concatenation and string interpolation are compiled to StringBuilder calls, so you don’t need to worry about this optimization.