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

Why Python, Ruby, and Javascript are Slow

speakerdeck.com

Post reply on HN
Print view View original

11–20 of 203 posts

Re: Why Python, Ruby, and Javascript are Slow

#11

Post by noelwelsh »

cheald wrote: post #4

Kind of a poorly-named deck. It's really about why programs use features of these languages that end up causing poor performance relative to C, rather than why the individual VMs themselves are slow. It's no surprise that trading the byte-precision of C for the convenience of a garbage collector and heap-allocated data structures results in a performance decrease. Dynamically-typed languages are often easier to progr…

It's not a given that GC is slower than manual memory management. See, for example, this work:

http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf

In a copy collector the GC time is proportional to the amount of live memory -- garbage is free. In FP-style programs (lots of short-lived allocations) GC can be essentially free.

The other main source of slowdown is to do with boxing and type checks. Accessing all data in a naive implementation of a dynamically typed language involves at least one type check and typically one pointer indirection to unbox the data. This can kill performance relative to the unboxed and unchecked equivalent. Consider, e.g., floating point operations -- they run in 1 cycle. If you add type check (2-3 cycles perhaps) and pointer indirection (10 cycles if it's in the cache) you can see how massive slowdowns easily arise.

Modern JS VMs will remove most of this cost. I doubt Python and Ruby do.

Basically, I would say it really depends on the interactions between the program and the language implementation.

Re: Why Python, Ruby, and Javascript are Slow

#12

Post by wmf »

TazeTSchnitzel wrote: post #7
cheald wrote: post #4

Kind of a poorly-named deck. It's really about why programs use features of these languages that end up causing poor performance relative to C, rather than why the individual VMs themselves are slow. It's no surprise that trading the byte-precision of C for the convenience of a garbage collector and heap-allocated data structures results in a performance decrease. Dynamically-typed languages are often easier to progr…

I'm certain you could have a language that is easy to program in, but doesn't use so much copying or use dictionaries so much. I'm not sure such a thing exists, though.

There's a whole continuum of stuff between Python/Ruby/JS and C, like Go, OCaml, and Rust. There's still a lot of refinement that could be done, though.

Re: Why Python, Ruby, and Javascript are Slow

#14

Post by mzs »

bcoates wrote: post #10
cheald wrote: post #4

Kind of a poorly-named deck. It's really about why programs use features of these languages that end up causing poor performance relative to C, rather than why the individual VMs themselves are slow. It's no surprise that trading the byte-precision of C for the convenience of a garbage collector and heap-allocated data structures results in a performance decrease. Dynamically-typed languages are often easier to progr…

If the deck is to be believed, it's not the garbage collector or the heap that's causing the performance loss, it's that APIs and algorithms they enable are allocation-heavy compared to other "faster" languages. Heap allocations are expensive even in non-GC languages.

The first example is lookup based on name, you can get away from that in python with slots but the common consensus is that it's not worth the performance improvement. That somehow translates into a dogma like, "Never use slots," but sometimes it is worth it.

Re: Why Python, Ruby, and Javascript are Slow

#15

Post by bithive123 »

If you want to learn more about what the Ruby VM has to do in order to execute your code, and some of the performance challenges for Ruby implementors (such as it's extremely flexible parameter parsing) I suggest this talk by Koichi Sasada: http://www.youtube.com/watch?v=lWIP4nsKIMU

Re: Why Python, Ruby, and Javascript are Slow

#16

Post by njharman »

Meh, MEH.

I'm almost never waiting on my python code. I'm waiting on network or disk or database or joe to check in his changes or etc.

I'm sure there are people who do wait. But that's why numpy, c extensions, all the pypy, psycho, and similar things exist.

Python and more broadly "scripting" languages are for speed of development. Something else can take on speed of execution faster than 90% of people need it to be.

Re: Why Python, Ruby, and Javascript are Slow

#17

Post by aroberge »

systematical wrote: post #6
arocks wrote: post #2

It is almost time that people stop referring to Languages as Fast or Slow. It is an implementation that is fast or slow, not a language.

I think its time people stop using shitty slide decks to get their point across.

Didn't it occur to you that these slides were for a presentation and that sharing them enable more people than just those that were at the presentation be informed of their content?

I, for one, am very grateful to speakers that make the extra effort required to share with a larger group what they have already shared (or are about to share) with a smaller group.

Re: Why Python, Ruby, and Javascript are Slow

#18

Post by algorias »

noelwelsh wrote: post #11
cheald wrote: post #4

Kind of a poorly-named deck. It's really about why programs use features of these languages that end up causing poor performance relative to C, rather than why the individual VMs themselves are slow. It's no surprise that trading the byte-precision of C for the convenience of a garbage collector and heap-allocated data structures results in a performance decrease. Dynamically-typed languages are often easier to progr…

It's not a given that GC is slower than manual memory management. See, for example, this work: http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf In a copy collector the GC time is proportional to the amount of live memory -- garbage is free. In FP-style programs (lots of short-lived allocations) GC can be essentially free. The other main source of slowdown is to do with boxing and type checks. Accessing all data…

> Modern JS VMs will remove most of this cost. I doubt Python and Ruby do.

In the python case, pypy removes this cost whenever it can. The less you use dynamic features like duck typing, the faster your code gets.

Re: Why Python, Ruby, and Javascript are Slow

#19

Post by cschmidt »

A nice talk. The punchline for me was:

    Things that take time
     •Hash table lookups
     •Allocations
     •Copying
Interestingly, that's exactly how you write fast C++ code. His point is that languages like Python lack good API's for preallocating memory.

Re: Why Python, Ruby, and Javascript are Slow

#20

Post by riobard »

Completely agree. APIs are so important for many optimizations to pull off.

I'd really like to use a lot more buffer()/memoryview() objects in Python. Unfortunately many APIs (e.g. sockets) won't work well with them (at least in Python 2.x. Not sure about 3.x).

So we ended up with tons of unnecessary allocation and copying all over the place. So sad.

Post reply on HN