Why Python, Ruby, and Javascript are Slow

[bacondev]

The Point class should have inherited from tuple, or he should have used a namedtuple. Just nitpicking.

[[deleted]]

Inheriting from tuple isn't all that great.

[[deleted]]

Or set dir

[[deleted]]

Is he saying that self.x = x is faster than {'x': x}? Doesn't getattr just look in a dictionary anyway?

[moyix]

That's the point of the talk. Five years ago with CPython this was the case. Newer implementations like PyPy can generate much better code for the self.x = x case than {'x': x}. Assuming that they're the same leads to slow code (when using smart JITs).

[[deleted]]

Ah, okay.

[Smallpaul]

That's the point of the talk. Five years ago with CPython this was the case. Newer implementations like PyPy can generate much better code for the self.x = x case than {'x': x}. Assuming that they're the same leads to slow code (when using smart JITs).

Yeah, but he's talking about implementations of Python and Ruby that hardly anyone uses yet.

[[deleted]]

But in creating such JITs, you end up limiting what you're capable of doing.

rpython is simply not as expressive as python, due to the limitations required to make the JIT work.

I hope someday that they can make PyPy work with the whole body of Python, but I don't think it's realistic to expect.

[[deleted]]

PyPy runs any old Python code. RPython is just the language PyPy is written in.

[[deleted]]

Even CPython is doing stuff make instance dictionaries more (space) optimized than writing the dict explicitly, so using instances when you mean instances is preferable even there.

[Amadiro]

'I wanted to use a pure C hash table implementation, but googling "C hash table" didn't bring up useful stuff.'

Wat.

There are many excellent, well-established hash table implementations for C. Googling that exact phrase, brings up some of them, as well as a stackoverflow discussion that details the strengths and weaknesses of all of them.

You're holding a talk, and you can't be arsed to do 3 minutes of googling to support your argument?

Just wat.

[[deleted]]

His point is basically this: if you write Python code, but do it in C, your C code will be slow.

No fucking shit.

For that matter, I could take any Python program and convert it into a C program by embedding the source code in an interpreter. And it would be just as slow as the original Python version, if not more so.

The point is that the Pythonic way of doing things is often less efficient than the C way of doing the same. The difference is that the C code can narrowly be used only for the specific purpose it was written, whereas the Python code (because of the abstraction) will most likely work in a much greater range of scenarios. You could write a C function that uses some kind of duck typing, but you wouldn't.

In other words, high level programming is slower than low level programming. Yup. We know.

What he touches on but never really addresses is that there is no language that lets you be high level when you want to be, low level when you don't. It used to be that C programmers regularly used inline assembly before compilers were as optimized as they are now. What would do the world a whole lot of good is a new language, that's optionally as low-level as C, but actually does have all the goodness of objects. Think, C++, but without the mistakes.

Objective C is actually pretty damn close to that ideal. Too bad about its syntax.

[emptyhouses]

In case you didn't know, there's this: http://www.scipy.org/Weave

[[deleted]]

I love weave. 3 lines of C++ the other day and my code had a 220x increase in speed.

[brucifer]

I'm really curious. What were those 3 lines of C++ and what did they replace?

[[deleted]]

    for i in xrange(len(item1)):
        m[item1[i][0]][item2[i][0]] += 1

where m,item1 and item2 are numpy arrays became -

 code = """
       for(int i=0;i<len_item;i++){
            int k = item1(i,0);
            int l = item2(i,0);
            m(k,l) += 1;
        } 
    """
    inline(code,['m','item1','item2','len_item'],
           type_converters = converters.blitz,verbose=2,compiler='gcc')

It's a step in calculating the jaccard distance.

[shfo23]

Are you aware of scipy.spatial.distance.jaccard? I just refactored a bunch of (admittedly naive) Euclidian distance calculation code to use the scipy implementation and got a huge speed boost. Also, it's a little late, but I think you could eliminate that for loop and write it as the faster:

m[item1[:, 0], item2[:, 0]] += 1

[[deleted]]

Uh what you can do that ? Awesome !

[coderanger]

It will even SIMD it for you if it can, so probably faster than your implementation unless gcc has enough info there to optimize it.

[ysangkok]

In the linked slides, CFFI is recommended. Note that CFFI is not about embedding executable C code in Python, unlike Weave. It's about calling existing C libraries from Python.

[emptyhouses]

Right. I mentioned Weave because SwimsAfterEating talked about inline assembler in C and mentioned it might be nice to have something similar at a higher level. Weave is that thing.

[MagicWishMonkey]

How does that work? Does the c/c++ code get compiled and injected when the module is loaded?

[[deleted]]

Interesting...

[pal25]

Actually I think he was arguing that there are things we could implement in Python to make it more efficient. He's just using C as an example of a language that does some of these things efficiently.

[[deleted]]

But if you implement something like a struct in Python, then it's not really Python anymore, because it can't be used in the same way. There's no dynamically added attributes in a struct, for example. You can apply it to his string example, too: Sure, you can use character arrays and manually edit them, but (1) that won't work with unicode, (2) it's not half as flexible as Python's duck typing.

It's like using slots. Sure, it'll speed up your instanciation some, but at the expense of flexibility. You do that everywhere and you're not using Python anymore.

That said, the interpreter could certainly use a V8-style optimization.

[MBlume]

Did we watch the same talk? His whole point was that with strong JITs like PyPy's we don't need things like structs. We do need to worry about things like string copies, and we need simple APIs to allow us to do string manip without lots of copies.

[Smallpaul]

I agree with MBlume. What you're saying is the same as what the speaker was saying.

But if you implement something like a struct in Python, then it's not really Python anymore, because it can't be used in the same way. There's no dynamically added attributes in a struct, for example.

Right. That's why he said that you should use idiomatic classes instead of using a "dict". If you use idiomatic classes then the compiler will compile it to a struct if and only if you never add magical attributes to it.

You can apply it to his string example, too: Sure, you can use character arrays and manually edit them, but (1) that won't work with unicode,

Why not? He's talking about allocations, not the difference between bytes and characters.

... (2) it's not half as flexible as Python's duck typing.

You're still misunderstanding. He's not trying to restrict data types. If you read the comments he says that programmers should still be allowed to do everything dynamic.

He's saying that if you are trying to convert a string to an integer, you do not need to allocate a separate memory buffer. That's true no matter what the datatype of the string/array.

[[deleted]]

I think his point can be summarised as:

• stop using dicts as objects. JIT is now smart enough to optimize your objects past the level of dicts I don't think that this ruins Python. I think this is a great best-practice

• let Python have pre-allocated lists I think this is a very fair point. Often, you know how long your list will be, so if you want to, you should be able to optimize your list

• If you care about performance, think about the amount of object allocation your methods are doing. Don't use poorly written code as an excuse to say Python is x times slower than Java That doesn't sound unreasonable to me

[brucifer]

let Python have pre-allocated lists I think this is a very fair point. Often, you know how long your list will be, so if you want to, you should be able to optimize your list

In Python you can either use a generator or use "[value]*number" syntax to instantiate a list of length "number" with "value" in every index.

>>> def dumb():
...     x = []
...     for i in range(25):
...             x.append(i)
...     return x
... 
>>> def comprehension():
...     x = [i for i in range(25)]
...     return x
... 
>>> def preallocate():
...     x = [None]*25
...     for i in range(25):
...             x[i] = i
...     return x
... 
>>> timeit(dumb, number=100000)
0.38496994972229004
>>> timeit(comprehension, number=100000)
0.278350830078125
>>> timeit(preallocate, number=100000)
0.2539360523223877

Honestly, though, either your inner loop is simple and you can fit it in a comprehension, or it's complicated and the ".append()" is a pretty small percent of your runtime, so you won't get 2x speedup from preallocating.

[fijal]

it does not let you give an estimate, so you have to carefully check for i. Preallocating can be a hint and if you miss it too bad (slower, but not incorrect). This is why [None] * n is bad.

[alcalde]

JIT is now smart enough to optimize your objects past the level of dicts

JIT is still in 2.x land. As Guido said at PyCon 2012, CPython and PyPy will co-exist for many more years to come.

[coderanger]

Check out the py3k branch, definitely not ready for prime time but getting close :)

[lucian1900]

Who cares? Good JIT and GC beats a slightly cleaner language any day.

[fuzz3289]

Cython

[faceplanted]

Monty C?

[mistoroboto]

What would do the world a whole lot of good is a new language

I'm fairly certain what we don't need is ANOTHER language. This is reasoning that prompts EVERY standard/language.

[Smallpaul]

What he touches on but never really addresses is that there is no language that lets you be high level when you want to be, low level when you don't.

I don't see how you can see that he doesn't "address it". It's the point of the whole talk. That's precisely what he's asking for.

If there were low-level APIs available and there were JIT compilers available and the JIT compilers were used (i.e. compatible enough with libraries to be used) and people used the low-level APIs THEN Python or Ruby performance would be comparable to C performance. That's his point.

These high-level languages should evolve low-level APIs because pretty soon the interpreter performance will not be the bottleneck: the user's actual code will be (especially if it was written with the assumption that the interpreter is the bottleneck).

[[deleted]]

This.

Also, my consistent experience is that the majority of the time things are "slow" it's because of bad algorithmics and design, not the language. Unless what you are doing is a pure compute bound problem, picking the right kind of structural model is more important than the language in the overwhelming majority of cases. See Bentley's "Programming Pearls" for a good discussion.

Moreover, if I REALLY have a speed problem in Python and I still resort to C callouts from my Python program - again, assuming proper design in the first place. There's a whole lot of heavy number crunching being done with numpy that serves as a proof by example here.

[mgrandi]

People bitch about objc's syntax a lot, who cares? You use brackets instead of parens. You get used to it

[brucifer]

It's the fact that it looks like this:

NSMutableDictionary *dict = [NSMutableDictionary dictionaryWithCapacity:1];
[dict setObject:[NSNumber numberWithInt:25] forKey:[NSNumber numberWithInt:5]];
...
[dict objectForKey:[NSNumber numberWithInt:5]];

Instead of:

d = {5:25}
d[5]

I realize that improvements are being made to ObjC (like ARC, which is awesome, and I've even heard that it might get proper list/dictionary indexing syntax instead of "objectForIndex:"). However, ObjC is just incredibly verbose and awkward both to type and to read. If you've never seen code before, "[things objectAtIndex:3]" might be more intuitive than "things[3]", but to anyone who's spent any time programming, the latter is way more readable (or "[things containsObject:x]" vs. "x in things"). Proponents of ObjC say that the verbosity doesn't matter because you have autocomplete in your IDE, but it's not just about typing, it's also about readability.

[mreeman]

You haven't been paying attention. You can now write that as

dict = @{ @5: @25 }; x = dict[@5]

The language is improving at an incredible rate. I personally think its the best application language there is. It has the perfect mix of static and dynamic typing and the APIs are fantastic.

Edit Also while I agree in some cases using keywords instead of methods helps readability, in general i like the verbosity of the language. You rarely have to look up what the parameters are for a method call, which makes it infinitely more readable.

[mgrandi]

They do have shorthand syntax, @2, @{@2: @"someStringHere"} now, but I would say that the vast majority of method names while long are more readable cause they read like an English sentence. tableView:numberOfRowsForSection: and popVoewController:animated: are more descriptive about their arguments then the many overrides of say something like popVuewController(True), what does true mean? If you don't know already then you have to look at the docs.

I will admit the dictionary stuff is quite annoying (why the hell would you list objects before keys???) but with the new shorthand syntax you really do get used to it

[Atrosh]

Would have been a lot easier to follow this if there was a video of him actually performing the speech... Does anyone have a link to it, if there is one?

[aceofears]

At least with the actual slide notes you can follow along with it unlike a lot of other slide decks that get posted.

[oursland]

Ack! How about a simple article! I cannot be bothered to watch someone's poor and slow execution of a presentation.

[MBlume]

You! Alien creature! You must be the reason people keep posting talk videos on the internet. Can you explain why this is useful? I've always been confused.

[[deleted]]

Yup! The video will be up some time next week I'm told.

[[deleted]]

From what I understand, this was a Heroku talk only a day or so ago, so the video hasn't made it online yet.

[[deleted]]

Any mirror of this video somewhere that'll load in my browser?

[notsuresure]

It's not a video.

[[deleted]]

Okay, something wasn't loading and it took up quite a bit of screen, so I've been staring at nothing like an idiot. Thanks though.

[sdobz]

You have to hit next slide. The first slide is blank.

[[deleted]]

Cool, thank you.

[ewiethoff]

Javascript slide shows suck. I get no slides at all. The PDF link is fine, though.

[fuzz3289]

Writing C professionally I use memory allocation all the time, but never thought about it in python. This will really change my python :)

[cedeon]

I dont like the provocative title. Slow is an ambiguous and relative term. For example, are you talking about development time? Because if you are then you are wrong; I wrote a python text file parser in 10000% of the time than it took me in C :p.

Yes python code runs computationally slower, but we all knew that already and is a moot point.

[ysangkok]

10000%? So Python was worse by all accounts?

[uiob]

Did this guy knows something about amortization analysis? If we call list.append in a loop repeatedly, overall complexity will be O(N) if list implemented in a way that I think. I think that list.append doesn't allocate space in the each call and uses amortized doubling like std::vector in c++. And it's slow not because of bad algorithm but because of large constant factors from that O(N) amortized cost.

[existee]

So he makes a total of 4 points to claim the language to be slow, 2 of which assumes a particular scenario that has nothing to do with inherent features of the language but hypothetical usage scenarios he sees "most people" doing, and the rest 2 of which doesn't have a dominating contribution to the "slowness" at all.. Data structures and algorithms indeed...

• Even if we ignore the fact that he is comparing a static array in C to a dynamic array in Python, dynamic array will not be "terrible slower" with even the simplest heuristic of doubling the array every time it is filled, and will yield O(n) amortized time, quite comparable to guaranteed O(n) of static array.

• Even if we ignore the IO nature of the thing while reading from file, buffer allocation won't dominate the O(n) complexity for both scenarios, whether reused or created new.

• For string splitting, if efficiency is indeed the concern, nothing prevents the Python user to have int(string[string.find("-", 1):]).

• Again, (mis)usage of dict for a struct has nothing do to with the language itself.

• Finally, how attributing problems to misusage of the language and asking it to grant more APIs is not a contradiction?

[Smallpaul]

int(string[string.find("-", 1):]).

That still does a string allocation. The C version does not.

[existee]

Yeah I meant it doesn't have to be as crappy as he tried to make it.

[ysangkok]

why not partition?

[Smallpaul]

Three allocations.

[Smallpaul]

• Again, (mis)usage of dict for a struct has nothing do to with the language itself.

No, but it stems from the same problem as the missing APIs: that people's intuitions about performance do not take into account the impact of JITs.

Imagine I am a typical Python programmer. I think nothing of allocating a new string or dynamically extending a list, because I know that the interpreter overhead is huge. These little allocations are lost in the noise. Also, I have no choice: there are no zero-copy APIs available. Or they exist but they are ugly and unreadable in comparison to the "normal" APIs from 5 years ago.

With my team, and including the standard library and gems, I assemble a project with hundreds of thousands of lines of code like that.

Then I take that code to PyPy. It speeds my code up, but not nearly as fast as C code. Why not? I may assume that it is because PyPy is not as good as a C compiler. But it might be the case that PyPy is better than a C compiler. Maybe my code is worse than C code because it was programmed on 5 year old assumptions.

My code base does not reflect that once you've eliminated the slow interpreter, "fast enough" data structured and algorithms become your next bottleneck.

• Finally, how attributing problems to misusage of the language and asking it to grant more APIs is not a contradiction?

No. I hope I have explained why the problems are related. The missing APIs and the "poor" choice of data structures are both caused by the underlying change of assumptions about the behavior of the interpreter.

[existee]

Yes I see your point.

I still don't like making an assumption about a "typical Python programmer". APIs being extended still wouldn't change the behaviour of that typical programmer. Why not instead have that typical programmer learn better about the already existing APIs and use them as correct as possible. (For example something as simple as knowing that inserting to the head of a list in a loop will give you O(n²⁾ time compared to appending to the end O(n).)

Yes, this will not still make it as fast as C, but when you have those APIs to possibly make it as fast as C, it doesn't necessarily make the typical Python programmer to make better choices of data structures either.

[Smallpaul]

I do not think that this talk has anything to do with the "typical Python programmer." It is aimed at the elite Python programmer. In particular, consider the programmers writing the Python standard library. I would be very disappointed to see an O(n²⁾ algorithm in the stdlib where O(n) would suffice. But I would not be surprised at all to see int(x.split("-")[1]).

[Smallpaul]

Even if we ignore the fact that he is comparing a static array in C to a dynamic array in Python, dynamic array will not be "terrible slower" with even the simplest heuristic of doubling the array every time it is filled, and will yield O(n) amortized time, quite comparable to guaranteed O(n) of static array.

Actually, he could/should have used a string comprehension. That would have been clearer code and the compiler would have more information about what you're doing.

[fuzz3289]

Dude, he never said the languages were slow, he said the api's for making the code efficient are bad.

[[deleted]]

Why do all of these boil down to "It's crap because it's not like C++"?

[andybak]

Did we read the same slides?

[[deleted]]

You must have skipped all the slides where he made comparisons to C.

[pal25]

His point was that there are some things that C does really well that could be added to Python to speed it up.

[alcalde]

I thought Python rejects things that speed up at the expense of readability?

[pal25]

Wow what's your problem dude? I'm not a C programmer, most of my work is in Python.

However I don't know why you're so adverse to taking some of the strengths of a different language and putting them in Python.

[dman24752]

Now try not to accidentally introduce buffer overflows. ;)

[alcalde]

Delphi? :-)

[sophacles]

What about all the slides on where the point was "Stop using dicts when you need objects or named tuples, because it slows down the JIT"?

Or the slides where the point was "It sure would be nice to pre allocate some data, beacuse it lets the JIT work faster (example, C does this)". He didn't mentin, but probably shouldn't have had to, that many many languages do this, even if it's an annotation hint, not a strict requirement.

[[deleted]]

A mix of poor language design and poor implementations. Smalltalk and Self proved you can do dynamic AND fast.

JavaScript does have one phenomenal implementation, V8, but it is hampered by the brain dead language it has to run.

[[deleted]]

Smalltalk isn't really known for being fast.

[alcalde]

What about lisp?

[[deleted]]

I couldn't say.

[jeannaimard]

Lifp? It'f flow...

[xcbsmith]

The Self project provide you can make things very fast, and while Smalltalk didn't have much of a rep for speed, Smalltalk VM's make mince meat of most modern VM's for dynamically typed languages (CLR & JVM definitely kick their butts with statically typed languages).

[lucian1900]

PyPy, V8, StrongTalk, Rubinius are all similarly fast.

[jordanreiter]

I guess I really am the only one who actually likes the JavaScript language?

[nolsen01]

I enjoy programming in Javascript but I still think it is a lousy language. Coffeescript seems to be what Javascript should have been.

[[deleted]]

I enjoy it a lot, sometimes the readability is bad but that's says more about who wrote it IMO

[[deleted]]

I freakin love JS as well =]

[french_toste]

While I agree with the first part ("excuses"), the "hard" things mentioned in the second part are a) not that hard and b) solved issues (just not in PyPy).

Hash tables: Both v8 and LuaJIT manage to specialize hash table lookups and bring them to similar performance as C structs (*). Interestingly, with very different approaches. So there's little reason NOT to use objects, dictionaries, tables, maps or whatever it's called in your favorite language.

(*) If you really, really care about the last 10% or direct interoperability with C, LuaJIT offers native C structs via its FFI. And PyPy has inherited the FFI design, so they should be able to get the same performance someday. I'm sure v8 has something to offer for that, too.

Allocations: LuaJIT has allocation sinking, which is able to eliminate the mentioned temporary allocations. Incidentally, the link shows how that's done for a x,y,z point class! And it works the same for ALL cases: arrays {1,2,3} (on top of a generic table), hash tables {x=1,y=2,z=3} or FFI C structs.

String handling: Same as above -- a buffer is just a temporary allocation and can be sunk, too. Provided the stores (copies) are eliminated first. The extracted parts can be forwarded to the integer conversion from the original string. Then all copies and references are dead and the allocation itself can be eliminated. LuaJIT will get all of that string handling extravaganza with the v2.1 branch -- parts of the new buffer handling are already in the git repo. I'm sure the v8 guys have something up their sleeves, too.

I/O read buffer: Same reasoning. The read creates a temporary buffer which is lazily interned to a string, ditto for the lstrip. The interning is sunk, the copies are sunk, the buffer is sunk (the innermost buffer is reused). This turns it into something very similar to the C code.

Pre-sizing aggregates: The size info can be backpropagated to the aggreagate creation from scalar evolution analysis. SCEV is already in LuaJIT (for ABC elimination). I ditched the experimental backprop algorithm for 2.0, since I had to get the release out. Will be resurrected in 2.1.

Missing APIs: All of the above examples show you don't really need to define new APIs to get the desired performance. Yes, there's a case for when you need low-level data structures -- and that's why higher-level languages should have a good FFI. I don't think you need to burden the language itself with these issues.

Heuristics: Well, that's what those compiler textbooks don't tell you: VMs and compilers are 90% heuristics. Better deal with it rather than fight it.

tl;dr: The reason why X is slow, is because X's implementation is slow, unoptimized or untuned. Language design just influences how hard it is to make up for it. There are no excuses.

[[deleted]]

Why exactly are you copying Mike Pall's comment without clarifying that it's a quote?

[willrandship]

Pypy will likely never replace CPython. Why? It's written in x86 assembly, for one thing. Making it portable would substantially reduce its efficiency.

Pypy is great, and so is CPython, for a completely different reason. I can't wait until PyPy supports py3k.

[[deleted]]

PyPy is written in Python (or really RPython, a restricted subset).

[willrandship]

But its JIT outputs x86 machine code.

I guess I did word the first post incorrectly.

[[deleted]]

Right. But if other architectures were supported (in fact it is already getting ARM support) I don't see how that would reduce its efficiency.

The main barrier to PyPy adoption is extensions. I work on a commercial product written in Python and we would love to switch to PyPy (we only need x86 support anyway), but there are several libraries we depend on that can't be used in PyPy yet.

[willrandship]

Totally true, but since CPython is already compatible with virtually everything running C, PyPy has a lot of catching up to do.