Why Python, Ruby, and Javascript are Slow
speakerdeck.com
Why Python, Ruby, and Javascript are Slow
1–10 of 203 posts
Re: Why Python, Ruby, and Javascript are Slow
#2It 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.
Re: Why Python, Ruby, and Javascript are Slow
#3Great bit of slides. Straight and to the point. If you've ever ventured under the hood of Python you'd see this in the code. If you've ever had to optimize the bejeesus out of code in C++ or C, you'd know exactly the kinds of things he's talking about.
Re: Why Python, Ruby, and Javascript are Slow
#4Kind 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 program in, but require more copying (and memory allocation) as a result. Hash tables are heap-allocated and have to be garbage collected, but they're flexible - something you don't get with structs. Allocating and freeing memory has a cost, and that can add up quickly. Your primary line of optimization in most of these languages is "avoid the GC", which really boils down to "don't allocate more than you need to", which is sound advice in every language, scripting or otherwise.
Re: Why Python, Ruby, and Javascript are Slow
#5It 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.
Have you considered reading the fucking presentation before snarking out on it?
Re: Why Python, Ruby, and Javascript are Slow
#6It 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.
Re: Why Python, Ruby, and Javascript are Slow
#7Kind 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.
Re: Why Python, Ruby, and Javascript are Slow
#8It 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.
Have you considered reading the fucking presentation before snarking out on it?
What makes you think I didn't? The author seems to agree with me. He even concludes that we should improve the implementation rather than the language for optimisation.
Re: Why Python, Ruby, and Javascript are Slow
#9It 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.
He gave a talk yesterday at Waza, Heroku's conference. I believe Heroku is planning on uploading videos of the talks in the coming days.
I've been interested in this talk since I saw it announced on Twitter, but prefer to watch/listen rather than go through these slides.
Re: Why Python, Ruby, and Javascript are Slow
#10Kind 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.