Nice post from the series.
While it's totally okay to [micro-]optimize specific functions for specific targets (e.g. Dalvik), the standard library implementation is "slow" not because it's not optimized, but, surprisingly, because it is!
While it's totally okay to [micro-]optimize specific functions for specific targets (e.g. Dalvik), the standard library implementation is "slow" not because it's not optimized, but, surprisingly, because it is!
https://twitter.com/romainguy/status/1754685096316350798
When designing API for millions of developers, the first thing in mind should be being concise and idiomatic: developers adopt practices and code from the standard library, so eventually, "idiomatic" Kotlin becomes widespread. And idiomatic code is easier to optimize
The original implementation tries to outsmart reality:
It has a branch for the very uncommon case in an attempt to be defensive and save some work. Which is then checked for later again, effectively being a dead code that slows down reasoning and execution
It has a branch for the very uncommon case in an attempt to be defensive and save some work. Which is then checked for later again, effectively being a dead code that slows down reasoning and execution
We are past this, it's 2015 already: !
It also tries to outsmart the compiler: "hey, I don't want an iterator of the string, thus I'll check each index individually to have charAt() called!" which, as we can see from the article, does not work well
And finally, it's not idiomatic. What we have is "if the string is not empty or for each index char at this index is blank" when what we *really* want is "every symbol of the string is blank".
Let's fix that and see how it goes?
Let's fix that and see how it goes?
'fun CharSequence.isBlank() = all { it.isWhitespace() }'. To no surprise, this version is as fast as the @romainguy one! 
@romainguy After our change, the code is how we intended to write it. Predictable and straightforward code is where the compiler shines -- no allocations, no need for escape analysis, no excessive branches. A few bytecode-level transformations and here we are
@romainguy What can we learn from this?
It's worth caring about the semantics, the intent of the code, its readability and conceptual clarity.
Don't try to outsmart the compiler unless you know precisely what you are doing. At the end of the day, the street always wins :)
It's worth caring about the semantics, the intent of the code, its readability and conceptual clarity.
Don't try to outsmart the compiler unless you know precisely what you are doing. At the end of the day, the street always wins :)
@romainguy Obligatory performance curve from @shipilev.
We came into "Debting on performance" in this one a few years ago, and now we pay the interest.
Don't do that, strive for beauty peak and the rest will follow
We came into "Debting on performance" in this one a few years ago, and now we pay the interest.
Don't do that, strive for beauty peak and the rest will follow
• • •
Missing some Tweet in this thread? You can try to
force a refresh
