I've seen several reports of pretty good performance improvements from the new JIT, but keep in mind a couple things:

It's included in the not yet finalized release that is currently only a release candidate. It's a little early to expect people to have experience with it. Some organizations might update quickly, but others will take quite some time. Also, the JIT isn't on all supported platforms; i think it's amd64 and aarch64 only at the moment, which probably covers most performance oriented servers, but maybe not everyone.

The other thing is it's not an optimizing JIT like Hotspot or v8; it 'only' turns the beam opcodes into native code as it's loaded. This eliminates interpretation overhead, but there's potential to optimize the native code in the future.

In my case it was a team of 1 working on OTP 19 and 20. Since that is now 3+ years ago, it is quite possible things have improved in the single-thread performance area.

Elixir single thread performance /is/ much faster than Ruby and Python [1].

Are you sure you weren't just doing something sub-optimal with Ecto?

[1] https://amp.reddit.com/r/elixir/comments/46v1l1/is_elixir_fa...

I'm a huge elixir fan, but in micro made up benchmarks I consistently see Ruby win over Elixir. I haven't run it with the jit.

One specific case that cripples Elixir - is as far as I know Elixir can't handle large multiplications efficiently. Ruby, Python use karatsuba or some derivative - from what I can tell multiplication in Erlang doesn't. Though I haven't actually asked anyone and was just poking around on my own.

example: Multiplying the first 100_000 numbers together I get

ruby multi.rb 3.47s user 1.91s system 99% cpu 5.396 total

elixir multi.exs 14.32s user 0.62s system 103% cpu 14.441 total

I was curious to see what my JIT build looked like for me so I ran the following: https://gist.github.com/cararemixed/c232b888b9dbdaeb67967f35...

This shows a significantly different story between the two with at least similar code. Note I am not trying to optimize for the fastest factorial here as both can be made much quicker but roughly equivalent code seems to tell a different story for me.

(NOTE: I put the code in a module as iex interpreted expressions on the top level are always slower than compiled modules, even when pasting them into iex. Doing the same for Ruby didn't show any difference for me.)

Neck in neck! That's amazing. Thanks for testing that out.

I wouldn’t call twice as fast neck and neck (others seem to show that the old interpreter is neck and neck) but the primitive JIT is clearly pulling ahead here.

The 3+ years ago is a good reference, thanks for sharing. The issue could also be Ecto related. Ecto 3, which might not have been out at the time, had a bunch of improvements on this front.