Scala 3 slowed us down?
kmaliszewski9.github.io
Scala 3 slowed us down?
1–10 of 195 posts
Re: Scala 3 slowed us down?
#2For me the main takeaway of this is that you want to have automated performance tests in place combined with insights into flamegraphs by default. And especially for these kind of major language upgrade changes.
Re: Scala 3 slowed us down?
#3Thank you for sharing. Interesting insight on dep libraries.
Re: Scala 3 slowed us down?
#4For me the main takeaway of this is that you want to have automated performance tests in place combined with insights into flamegraphs by default. And especially for these kind of major language upgrade changes.
What are folks using for perf testing on JVM these days?
Re: Scala 3 slowed us down?
#5I am not a scala fan and do not care for it, but I upvote for the thorough thought process, breakdown, and debugging of the problem. This is how technical blogs should be written. AI aint got shit on this.
Re: Scala 3 slowed us down?
#6The only issue I have with Scala 3 is Python envy, they should not have come up with a second syntax, and pushing it as the future.
If anything is slowly down Scala 3 is that, including the tooling ecosystem that needs to be updated to deal with it.
Re: Scala 3 slowed us down?
#7> After upgrading the library, performance and CPU characteristics on Scala 3 became indistinguishable from Scala 2.13.
We had a similar experience moving Ruby 2->3, which has a ton of performance improvements. It was in fact faster in many ways but we had issues with RAM spiking in production where it didn't in the past. It turned out simply upgrading a couple old dependencies (gems) to latest versions fixed most of the issues as people spotted similar issues as OP.
It's never good enough just to get it running with old code/dependencies, always lots of small things that can turn into bigger issues. You'll always be upgrading the system, not just the language.
Re: Scala 3 slowed us down?
#8For me the main takeaway of this is that you want to have automated performance tests in place combined with insights into flamegraphs by default. And especially for these kind of major language upgrade changes.
What are folks using for perf testing on JVM these days?
jmh is what I've always used for small benchmarks.
Re: Scala 3 slowed us down?
#9I was involved in a Scala point version migration (2.x) migration a few years ago. I remember it being painful. Although I recall most of the pain was around having lots of dependencies and waiting for libraries to become available.
At the time Scala was on upswing because it had Spark as its killer app. It would have been a good time for the Scala maintainers to switch modes - from using Scala as a testbed for interesting programming-language theories and extensions to providing a usable platform as a general commercially usable programming language.
It missed the boat I feel. The window has passed (Spark moved to Python and Kotlin took over as the "modern" JVM language) and Scala is back to being an academic curiosity. But maybe the language curators never saw expanding mainstream usage as a goal.
Re: Scala 3 slowed us down?
#10In Scala 3, the inline keyword is part of the macro system.
When inline is used on a parameter, it instructs the compiler to inline the expression at the call site. If the expression is substantial, this creates considerable work for the JIT compiler.
Requesting inlining at the compiler level (as opposed to letting the JIT handle it) is risky unless you can guarantee that a later compiler phase will simplify the inlined code.
There's an important behavioral difference between Scala 2 and 3: in 2, @inline was merely a suggestion to the compiler, whereas in 3, the compiler unconditionally applies the inline keyword. Consequently, directly replacing @inline with inline when migrating from 2 to 3 is a mistake.