Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala 3 slowed us down?

kmaliszewski9.github.io

Post reply on HN
Print view View original

61–70 of 195 posts

Re: Scala 3 slowed us down?

#61

Post by gavinray »

dtech wrote: post #34
munchler wrote: post #22

I’m not familiar with Scala’s macro system, but it seems like a big takeaway here is: Be careful with code that invokes the compiler (JIT) at runtime. That seems like it’s asking for trouble.

Macro's are compile time, there is no runtime codegen. The problem was overly-frequent inlining generating enormous expressions, causing a lot JIT phase and slow execution.

That's not true, Spark's entire query engine relies on use of runtime codegen via macros/quasi quotes

Look up the architecture of Catalyst + Tungsten

https://www.databricks.com/glossary/catalyst-optimizer

Re: Scala 3 slowed us down?

#62

Post by malkia »

spockz wrote: post #2

For 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.

Benchmarking requires a bit of different setup than the rest of the testing, especially if you want down to the ms timings.

We have continous benchmarking of one of our tools, it's written in C++, and to get "same" results everytime we launch it on the same machine. This is far from ideal, but otherwise there be either noisy neighbours, pesky host (if it's vm), etc. etc.

One idea that we thought was what if we can run the same test on the same machine several times, and check older/newer code (or ideally through switches), and this could work for some codepaths, but not for really continous checkins.

Just wondering what folks do. I can assume what, but there is always something hidden, not well known.

Re: Scala 3 slowed us down?

#63

Post by spockz »

esafak wrote: post #4
spockz wrote: post #2

For 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?

I use jmh for micro benchmarks on any code we know is sensitive and to highlight performance differences between different implementations. (Usually keep them around but not run on CI as an archive of what we tried.)

Then we do benchmarking of the whole Java app in the container running async-profiler into pyroscope. We created a test harness for this that spins up and mocks any dependencies based on api subscription data and contracts and simulates performance.

This whole mechanism is generalised and only requires teams that create individual apps to work with contract driven testing for the test harness to function. During and after a benchmark we also verify whether other non functionals still work as required, i.e. whether tracing is still linked to the right requests etc. This works for almost any language that we use.

Re: Scala 3 slowed us down?

#64

Post by hunterpayne »

The problem with Scala 3 is that nobody asked for it. The problem with Scala 2 is that the type inference part of the compiler is still broken. Nobody worked on that. Instead they changed the language in ways that don't address complaints. Completely ignore the market and deliver a product nobody wants. That's what happened here.

PS Perhaps they should make an actual unit test suite for their compiler. Instead they have a couple of dozen tests and have to guess if their compiler PR will break things.

Re: Scala 3 slowed us down?

#65

Post by malkia »

gedy wrote: post #11
pjmlp wrote: post #6

The 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.

As a former Scala fan, wow you aren't kidding, wth val month = i match case 1 => "January" case 2 => "February" // more months here ... case 11 => "November" case 12 => "December" case _ => "Invalid month" // the default, catch-all // used for a side effect: i match case 1 | 3 | 5 | 7 | 9 => println("odd") case 2 | 4 | 6 | 8 | 10 => println("even") // a function written with 'match': def isTrueInPerl(a: Matchable): B…

Sorry, I'm coming from C++-ish background - can anyone explain what's going on :)

Re: Scala 3 slowed us down?

#66

Post by spockz »

pjmlp wrote: post #47
noelwelsh wrote: post #37

Earlier quoted context omitted.

Everything is up to date with the new syntax as far as I'm aware. Also, the compiler and scalafmt can rewrite one to the other. A project can pick whatever style it wants and have CI reformat code to that style.

When I checked a year ago, the IDE tooling still wasn't quite there.

What I don’t get because there is LSP and BSP support. What else is needed to get support for scala 3 from an IDE? Obviously, Kotlin coming from Jetbrains will make it receive a lot more love and first class support.

Re: Scala 3 slowed us down?

#67

Post by wrathofmonads »

derriz wrote: post #9

I 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 inter…

Kotlin hasn’t made much of an impact in server-side development on the JVM. I’m not sure where this perception comes from, but in my experience, it’s virtually nonexistent in the local job market.

Re: Scala 3 slowed us down?

#68

Post by hunterpayne »

pjmlp wrote: post #56
dtech wrote: post #52

Earlier quoted context omitted.

Kotlin existed before Java 7 and kept support JVM 1.6 for a long time (mainly because of Android) Even then, they benchmarked it, and inlining was still faster* than invokedynamic and friends, so they aren't changing it now JVM 1.8+ is a requirement. * at the expense of expanded bytecode size

Java 7 to Java 25 is a world apart, and then on which JVM? Naturally it is a requirement, JetBrains and Google only care about the JVM as means to launch their Kotlin platform, pity that they aren't into making a KVM to show Kotlin greatness. If it feels salty, I would have appreciated if Android team was honest about Java vs Kotlin, but they weren't and still aren't. If they were, both languages would be supported a…

Maybe the JVM team should listen to the market then and disable the jigsaw encapsulation that keeps devs on 1.8. Forcing a questionable security framework on everyone is why 1.8 is still used. Again, this is a problem because the PMs (and some devs) refuse to listen to what the market wants. So they are stuck keeping a 20 year old version of the code working. Serves them right to have to do this. It is their penance for being too arrogant to listen to the market.

PS Yes, I know, there is some weird way to disable it. Somehow that way changes every version and is about as non-intuitive as possible. And trying to actually support the encapsulation is by a wide margin more work than it is worth.

Re: Scala 3 slowed us down?

#69

Post by spockz »

malkia wrote: post #62
spockz wrote: post #2

For 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.

Benchmarking requires a bit of different setup than the rest of the testing, especially if you want down to the ms timings. We have continous benchmarking of one of our tools, it's written in C++, and to get "same" results everytime we launch it on the same machine. This is far from ideal, but otherwise there be either noisy neighbours, pesky host (if it's vm), etc. etc. One idea that we thought was what if we can ru…

I agree for measuring latency differences you want similar setups. However, by running two versions of the app concurrently on the same machine they both get impacted more or less the same by noisy neighbours. Moreover, by inspecting the flamegraph you can, manually, see these large shifts of time allocation quickly. For automatic comparison you can of course use the raw data.

In addition you can look at total cpu seconds used, memory allocation on kernel level, and specifically for the jvm at the GC metrics and allocation rate. If these numbers change significantly then you know you need to have a look.

We do run this benchmark comparison in most nightly builds and find regressions this way.

Re: Scala 3 slowed us down?

#70

Post by wrathofmonads »

frje1400 wrote: post #36
esafak wrote: post #18

Earlier quoted context omitted.

Java's new features are always going to be on paper. The ecosystem, with all its legacy code, is always going to be a decade behind. And if you are starting a new project, why would you pick Java over Kotlin?

> And if you are starting a new project, why would you pick Java over Kotlin? Because in 5-10 years you'll have a Java project that people can still maintain as if it's any other Java project. If you pick Kotlin, that might at that point no longer be a popular language in whatever niche you are in. What used to be the cool Kotlin project is now seen as a burden. See: Groovy, Clojure, Scala. Of course, I recognize tha…

Clojure has never been a popular language, nor has it aimed to be mainstream. That is the Lisp curse. It has never positioned itself as a "better Java". It shines in applications where immutable, consistent, and queryable data is crucial, and it has found another niche in UIs through ClojureScript.
Post reply on HN