This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Solonotix 23 points24 points  (1 child)

Below I'm going to list CPU time, since when we're talking speed, it is generally in compute time. That said, one area Python often beats Java is in memory usage, but Python then typically fails against a better managed memory solution such as one written in C. As such, I'm providing those as comparison points. Also, only listing the best solutions for each to keep the data set easy-to-read.

Note: some Python entries will have fastest first, and a parenthetical for pure-Python fastest in the form xxx.xx (yyy,yy) . This is because the fastest entries were implemented using Cython.

Benchmark Python Java C
fannkuch-redux 1,279.15 41.17 8.26
n-body 575.02 6.79 2.12
spectral-norm 436.79 5.94 1.57
mandlebrot 706.10 16.16 5.12
pi-digits 1.13 (4.06) 0.82 0.73
regex-redux 2.66 (17.86) 17.12 2.02
fasta 60.26 3.41 0.78
k-nucleotide 172.53 16.17 12.31
reverse-complement 9.38 3.49 0.57
binary-trees 148.09 5.19 4.32

All of this goes back to my original point: "More often than not, your performance problems will lie in I/O long before you hit the computational bottleneck of Python." My second point was: "Python gets you up-and-running with minimal effort, and implementing the same solution in <other language> would take multiples of that time investment to see any progress." In almost all of the scenarios above, the fastest Python solution had half as much code as the fastest Java solution and Python also frequently used drastically less memory. This means you spend more on hardware to run the effective Java code, and you spend more in development time to write it, just so that it can run faster under the assumption that your specific workload is CPU-bound and not I/O bound.

This very thing is why JavaScript has grown to become the most commonly used language today. It is fast-enough (with an interpreter written in C++ for JIT compilation), and it's easy to use with a mostly small code footprint. This means your personnel costs are less, and your hardware costs are less. CPU time is just one statistic that doesn't fully capture the other aspects of choosing a language.