search

niklas-heer / speed-comparison

A repo which compares the speed of different programming languages.
https://niklas-heer.github.io/speed-comparison
MIT License
508 stars 79 forks source link

Translate Java solution to Clojure #56

Closed serioga closed 2 years ago

niklas-heer commented 2 years ago

Very interesting results. It made Clojure faster, but Clojure via Babashka slower 🤔 😅 combined_results

niklas-heer commented 2 years ago

@serioga thank you very much for your contribution! In general, I think I choose speed improvements done to the "main implementation" of a language rather than something like Babashka and PyPy.

serioga commented 2 years ago

Hm, still slower then I expected. Need to check benchmark methodogy...

serioga commented 2 years ago

Probably you measure app starting time, which is slower for Clojure comparing to Java

niklas-heer commented 2 years ago

@serioga yes that is correct, currently startup and IO are included. There are some thoughts (#59) of getting "clean" data just for computing pi, but nothing is implemented yet.

serioga commented 2 years ago

OK, but for Clojure those figures are misleading :-)

serioga commented 2 years ago

In my tests this code was executed in about 400 ms. And previous one was about 2500 ms. Also Java warms up and works faster after this :-)

niklas-heer commented 2 years ago

It depends on what you use Clojure for. For a long-running application, I agree. For a CLI application which is invoked from time to time, it's closer to what can be expected, imho.

niklas-heer commented 2 years ago

I think that is why I would like to capture both data with startup and IO and just plain pi calculation in the future.

serioga commented 2 years ago

I would test nbb for CLI application. Also I would test something more long running (what requires tens seconds) to reduce significance of startup time. For startup time I would make separate test with zero op script, to measure which solutions are faster for launching short-term CLI apps.

giordano commented 2 years ago

Note that we had been advocating for this kind of changes in #13, #22, #35, etc... 🙂