Hacker News new | ask | show | jobs
by dr_zoidberg 3297 days ago
Python 3.6.1 is a lot faster than 3.3.2 which was used back when the heap benchmark was done. In my system, 2.7.10 vs 3.6.1:

    C:\Test\PyBench>py -2 test.py
    Done in 1188.308127
    
    C:\Test\PyBench>py -3 test.py
    Done in 1454.897614
Please bring up to date benchmarks to the discussion, and stop complaining about old problems.

Note: adjusted I the workload to be 1000 less iterations, to get the results fast for this comment, so this numbers aren't comparable to the list in the github repo. But even if I hadn't done that, they wouldn't be because I ran these in my system.
1 comments
baldfat 3297 days ago
Python, R and other languages are just slower. If that is an issue I again will agree you need to move to another language.

Can I ask what you need the speed for? How long are your reports running? Because a lot of times the reports run in under a few minutes and people just don't sub-set their data to code on. People feel it is "BIG DATA" when it is just annoying data that takes less then a minute to spit out.

link
holistia 3297 days ago
The coalescence around Python and R for numerics to the extent it did was kind of premature. They're both great languages but I've given up on implementations of either of them achieving the kinds of speeds that they should be at for the things people are using them for.

I think there'll be more traction expanding the libraries for Julia, Nim, or Kotlin, all of which are much faster than Python, and similar in expressiveness. It's probably easier to create an optimization/ML/linear algebra/RNG/whatever library in Julia, Nim, or Kotlin than trying to get good performance out of R or Python.

I completely understand PyPy and numpy and why Python and R became popular, because there was a need for expressivity in the numerics space and other languages weren't offering it. But if you've been following them for long enough, it's clear that both of them had problems under the hood. I think people just crossed the boundary of appropriate use at some point, because the language syntax is so appealing for these sorts of things.

Maybe I'm wrong about all this and Pypy will deliver but I'm not holding my breath any longer. No offense to the Pypy developers--I'm immensely impressed with their work, and they've produced much more than I ever thought--but I do see some sort of asymptote. I think it would take some serious corporate influx of effort like what happened with javascript, and even then I worry that compatibility issues would rear their head. My guess is the Python 2-3 split would become a Python 2-3-Pypy split--maybe that's fine though.

link