Why Python is Slow: Looking Under the Hood

http://jakevdp.github.io/blog/2014/05/09/why-python-is-slow/

by underyx • 12 years ago

208 174 12 years ago

jakevdp.github.io

ape4• 12 years ago

This is hardly breakthru stuff.

phorese• 12 years ago

True. It also never claims to be.

The very first part says that this is only a writeup for people who are not intimately familiar with why "dynamically typed" might slow down Python.

falcolas• 12 years ago

Based off my own experience, dynamic typing has much less to do with slowness than the plethora of string copying which occurs in your typical python script.

rpearl2• 12 years ago

  > binary_add<int, int>(a, b)

no... there is simply not function call overhead for adding two integers in C.

zhemao• 12 years ago

It's just notation, to make it clear that two integers (and not some other type of object) are being added.

rpearl2• 12 years ago

It's just not good notation at all, though. It strongly implies "call". And "object". This is misleading.

Rusky• 12 years ago

It's inlined ;)

kghose• 12 years ago

The 'slow' part wasn't so new to me, but the `id` command and the attendant understanding that smply typing 110 in the interpreter creates an OBJECT and when you assign a=110 `a` points at that object (and when you reassign a=30, a new object is created and a points at that), blew my mind. Thanks for this!

Previously I had thought that doing a=110 creates an object 'a' that stores the value 110 (and when we do b=a, b simply points to a). I had no idea there is a third object in play.

taejo• 12 years ago

`a=110; b=a` involves only one object: 110. a and b are just names.

dekhn• 12 years ago

And 110 is probably an interned int, so a and b are likely referencing an object that was compiled into the interpreter.

stuki• 12 years ago

That's pretty central to any OO language. "Everything's an object." Veering away from that, only serves to turn the language into a mess of boxing and unboxing.

That's not to say that OO is necessarily the ideal language paradigm, but it has certainly been the most dominant in the era Python has existed.

theseoafs2• 12 years ago

OO languages do not have to do this. Ruby doesn't, for instance (that is, it turns the language into a "mess of boxing and unboxing", but that's invisible to the programmer and makes working with integers so much more efficient). There's simply no reason to allocate integers on the heap -- it's a bad design desicion.

wyager• 12 years ago

Something I noticed a while back is that Python already has objects pre-made for the small integers.

koenigdavidmj2• 12 years ago

That's common. Same for the one-character strings.

That's a sticking point with a lot of young Java programmers encountering boxed types for the first time. They see that x is true here:

  Integer x = new Integer(5);
  Integer y = new Integer(5);
  x == y

But this is false:

  Integer x = new Integer(5000);
  Integer y = new Integer(5000);
  x == y

(The real fix, of course, is to use the 'equals' method when comparing objects.)

sqrt17• 12 years ago

Actually, it's a bit more complicated: for small integers, the Python runtime has a stash of pre-made objects. For compiled code, the code may include a static reference to a constant object.

Which means that, if you execute "a = 110" a bunch of times, no new objects get created. If you execute "a= 110+300" a bunch of times, a whole bunch of new objects is created and destroyed.

By the way, this boxing/unboxing logic is also at work when you stick numbers into a standard HashMap, since it stores Integer objects and not the primitive type. However, in Java you can use GNU Trove's IntObjectHashMap or ObjectIntHashMap and save some memory, whereas Python's "everything is an object" rules this out (unless you're using PyPy and its tracing jit which figures out that a always contains a number).

Fede_V• 12 years ago

Jake's blog is pretty great. I really suggest reading more stuff in there if you care about scientific computing.

williamstein• 12 years ago

This is convenient, since it's almost exactly what I plan to talk about in the undergrad class I'm teaching today (https://github.com/williamstein/sage2014). I view this sort of article as good motivation for Cython, and the value of this article is merely that it aims at typical undergraduates not in computer science.

pnathan4• 12 years ago

One thing that bothers me - and has for a long time - is why Python (Perl, Ruby, etc), never have really leveraged the work Common Lisp systems have done (CMUCL, SBCL, etc), which provide very good performance without sacrificing dynamic typing or the REPL.

agentultra3• 12 years ago

It bothers me too.

Dynamically typed does not imply no types. A good CL implementation takes that to heart and produces really nice code out of the box. And the language spec provides for an API to allow program developers to specify types and hints to the compiler to optimize certain functions and code paths where it's needed.

The benefit from this is that you can rapidly prototype your application and harden it to the platform you deploy on when performance becomes an issue... and with built-in conditional compilation you can do that in a cross-platform way.

mikeklaas• 12 years ago

Python has types; I would even describe it as strongly-typed. It is thus relatively JIT-able (as pypy and psyco have shown).

The chief problem is the high level of dynamic typing going, plus the huge amount of globally-changable assumptions (you can add methods to any instance of a class, you can globally change the definition of language built-ins, etc.)

WaxProlix• 12 years ago

What work specifically are you referencing?

agentultra3• 12 years ago

Maybe:

http://www.flownet.com/gat/papers/lisp-java.pdf

http://www.iaeng.org/IJCS/issues_v32/issue_4/IJCS_32_4_19.pd...

pnathan4• 12 years ago

JIT compiling to native code from the REPL is a big one.

chrisseaton2• 12 years ago

Languages like Python and Ruby have generally looked to the SmallTalk and Self literature (inline caches, dynamic deoptimization, hidden classes etc) rather than Common Lisp, so people aren't ignorant of the research, they're just looking in a different area. If you think there's something in Common Lisp we're missing, point it out!

pnathan4• 12 years ago

Well, you are missing compilation to native code. Common Lisp has very good performance characteristics in the hands of an expert, whereas $modern_dynland usually winds up requiring a call out to C, fragmenting the codebase and requiring dual-expertise (one in $dyn_lang, one in C) to maintain effectively.

I don't meant to say USE LISP (but you know, it's available and ready to go!), but I do mean to say: the knowledge (algorithms, research papers, implementations) on how to do this relatively efficiently was developed in the late 70s and early 80s.

edit: SBCL is a good example of what can be done with this knowledge. I would be 100% unsurprised if perl/python/ruby could benefit from these algorithms. See phkoung's blog for what he did with SBCL on numerical analysis and high performance Lisp.

jules• 12 years ago

Python is a very different language than Lisp. It's much more dynamic. Every method call conceptually involves a hash table look up. Lisp on the other hand is much closer to the bare metal, and much easier to implement efficiently. For Python the implementation techniques of Self would be more appropriate.

lispm9• 12 years ago

Every method call conceptually involves a hash table look up

Like CLOS.

ScottBurson• 12 years ago

And the easiest way to leverage that effort is to use CL as an implementation platform. Whatever you think of CL as a language to program in directly, it really shines as a language to implement dynamic languages in. You get a lot of useful pieces, including native-code compilation, some very powerful control-flow operators, multithreading (in most implementations), and of course garbage collection, for free.

There's a more subtle benefit as well. Because compilability was a key goal in the design of CL, using it as a translation target while you're designing a new dynamic language will help you make sure your language is also efficiently compilable.

EDITED to add: in CL, the whole tagged-pointer thing has been taken care of for you, so you don't have to think about it (cf. [0]). This means you get fixnums (unboxed immediate integers), with automatic overflow to bignums (arbitrary-precision integers), for free. In fact there's the whole CL numeric tower, including ratios and complex numbers. Other goodies: multiple inheritance. Multimethods (multiple dispatch). Class creation and redefinition at runtime.

It baffles me that anyone would want to reimplement all that stuff, or even part of it.

[0] https://mail.python.org/pipermail/python-dev/2004-July/04614...

codegeek• 12 years ago

Good read. Whenever I read stuff like this, I always wonder if it is always true that dynamically typed languages are slower than statically typed languages ? Also, do we have to take this for granted that more higher level the language is, the slower it will be ? Or are there exceptions ?

Also, it is worth asking if for majority of use cases of python for data/analysis, the ease and flexibility outweights the slowness.

YZF• 12 years ago

Always is a bit of a strong word but yes, it's always true.

Virtual functions in C++ which allow some form of dynamic behaviour are slower than static function calls because they inherently involve another level of indirection. Static calls are known at compile time, they can be inlined by the compiler, they can be optimized in the context in which they're called. Now, nothing prevents the C++ run-time from trying to do the same thing at run-time but you can relatively easily see that it'll have to make some other compromised to do so. Nothing prevents a C++ program from generating C++ code at run-time, compiling it, and loading it into the current process as a .so. Now that's a pretty dynamic behaviour but there's again an obvious price. You can also write self modifying code. At any rate, static languages are capable of the same dynamic behaviour that dynamic languages are capable of but you often have to implement that behaviour yourself (or embed an interpreter...).

Fundamentally, a dynamic language can't make the kinds of assumptions a more static language can make, it can try and determine things at run-time (ala JIT) but those take time and still have to adapt to the dynamics of the language. The same line of code "a = b + c" in Python can mean something completely different every time it's executed so the run-time has to figure out what the types are an invoke the right code. Now the real problem is that if you take advantage of that then no one can actually tell what this code is doing and it is utterly unmaintainable.

To compound the problems facing dynamic languages is the fact that CPUs are optimized for executing "predictable" code. When your language is dynamic there are more dependencies in the instruction sequence and things like branch prediction may become more difficult. It also doesn't help that some of the dynamic languages we're discussing have poor locality in memory (that's an orthogonal issue though, you could give a dynamic language much better control over memory).

EDIT: One would think it should be possible to design a language which has both dynamic and static features where if you restrict yourself to the static portion runs just as fast as any other statically compiled language and still allows to switch to more dynamic concepts and pay the price when you do that.

Solarsail2• 12 years ago

Apologies if you've already read this, but this paper was absolutely enlightening for me on what a more performant Python would look like: http://julialang.org/images/julia-dynamic-2012-tr.pdf especially section 2 on language design, which discusses how it's actually different.

(And yes, I know I'm just adding to the people plugging Julia here) Among other things, Julia actually avoids forms of dynamism that are in practice rarely employed by programs in dynamic languages. Existing code is immutable, but new code may always be generated if different behaviour is desired.

I'm not entirely sure if I could accurately say Julia allows one to trade between efficiency and dynamism when each is desired, but it does appear to be a much better balanced approach than is normal.

logicchains2• 12 years ago

It's not always true in practice. See for instance: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

Common List on SBCL is often faster than F# on Mono, eve though Mono is statically typed, as the former runtime has had a lot more work put into optimising it.

Or, compare F# on Mono with Clojure on the OpenJDK: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

Clojure again is faster, due to a more optimised runtime.

gregwebs2• 12 years ago

    Dynamic typing makes Python easier to use than C

I disagree with the implications. The main reasons Python is easier to use is independent of type system. Not having to manually manage memory, for example! Overall it is a higher-level language, whereas C is designed for maximum performance.

Dynamic typing is probably preferable to a 40 year old type system. But Python could be easier to use (catch bugs ahead of time!) and execute faster by adding a modern type system. Optional typing (like TypeScript or Facebook's new PHP implemntation) would probably be appropriate.

michaelmior• 12 years ago

Cython[1] is the closest I'm aware of to optional type annotation for Python. It works quite well, although requires a separate compilation step and the source code is no longer Python.

I assume by "new PHP implementation", you're referring to Hack[2] which is a different language, although heavily based on PHP. (I believe Hack is a superset?)

[1] http://cython.org/ [2] http://hacklang.org/

nly6• 12 years ago

Cython actually shows the cost of interpretation quite well. Even without added type declarations it speeds up a quicksort of a list of integers by anywhere from 40-50%.

https://github.com/psoberoi/stepanov-conversations-course/tr...

I certainly don't see Cython as anything but a quick way to get efficient C code in to Python module though... you typically get the worst of both worlds with compilation + dynamic typing.

maxerickson2• 12 years ago

There is support in Cython for doing the compilation transparently:

http://docs.cython.org/src/tutorial/cython_tutorial.html#pyx...

girvo2• 12 years ago

Well yes, Hack is a "new language" in a similar way TypeScript is, but Hack is built to interoperate with regular PHP code. It's a superset, similar to how Objective-C was/is with C, only even more integrated with it's subset language :)

Regardless, it's damned nice (especially with TypeScript on the front end: static optional typing everywhere!)

chriswarbo2• 12 years ago

Dynamic typing is probably preferable to a 40 year old type system.

I don't think ML users will agree ;)

munro• 12 years ago

Please continue! Don't leave us hanging for the riveting conclusion :) I don't know ML so I would love to hear another perspective

freyrs33• 12 years ago

Both System-F and Martin-Löf type theory are roughly 40 years old as well.

Spittie• 12 years ago

I'd love to see optional typing in Python, I wonder if there is any official reasons about why it never got introduced.

I very rarely change the type of a variable, so it would be essentially free speed and free speeds for me.

I actually wonder, do people use dynamic typing so often? I mean, it's nice to do "variable = int(variable)" when I know that I'm getting an integer in a string, but that's probably the only use case can I can think off that doesn't just reuse variables for something else.

collyw2• 12 years ago

I started programming in Java, and moved to Perl and now Python. At first it seemed a bit weird, dynamic typing, but now I embrace it and enjoy the flexibility it offers. I see that many people prefer static typing and I am not sure why.

Can someone give me a concrete example of when static typing would be beneficial? (The majority of my work revolves around databases, so I guess I rely on that as a kind of type checking to a degree).

nairteashop• 12 years ago

I'd love to see optional typing in Python, I wonder if there is any official reasons about why it never got introduced.

Here are a few from Guido himself (not really anti static-typing, but just walking you through pros/cons as he sees them). Great reads:

http://www.artima.com/weblogs/viewpost.jsp?thread=85551

http://www.artima.com/weblogs/viewpost.jsp?thread=86641

http://www.artima.com/weblogs/viewpost.jsp?thread=87182

skriticos2• 12 years ago

In my experience the dynamic typing is very useful when you start to do collections and nested data structures. You easily create a mixed type nested directory tree with only a few lines of code without all that boilerplate.

gizmo686• 12 years ago

There is no reason you can not have something like "variable = int(variable)" in a strongly typed system. In fact, Haskell lets you do (essentially) this by shadowing variables. This particular example wouldn't work, because Haskell would view it as a recursive definition, but there is no reason you couldn't design a language so that the asignee side looks at the pre-shadow variable.

njharman2• 12 years ago

I consider http://cython.org/ to be the "optional typing" implementation of Python.

benselme• 12 years ago

Optional typing is the main goal of the mypy project: http://www.mypy-lang.org/

nkozyra• 12 years ago

I always wondered why more languages didn't do this with the goal - ostensibly - being faster overall performance.

At the same time I hate it when syntax vacillates wildly from application to application.

sgt1012• 12 years ago

Ok, I wanted to write "julia, julia, julia..." (check out the varargs) but I shall be sensible. Julia's syntax is what an algol culture programmer would expect in order to deal with a late 2000's concept of typing. It has the HCI virtue of being what I (you?) expect.

At the same time it is 40x faster (in my applications developed in a fortune 500 company, ok the research bit - but still delivered for use if not prod) than python.

Now, if only we got it running in SPARK...

Perseids2• 12 years ago

> Dynamic typing makes Python easier to use than C
Overall it is a higher-level language, whereas C is designed for maximum performance.

I agree with most of your points, but on this I think you are comparing apples to oranges. C is not designed for maximum performance, but as a system language and as such only as slim abstraction over assembler. As a side effect it allows for maximum performance. A more fair comparison (pretty much every widely used language is easier to use than C) would be C++ vs. Python, where in C++ most - if not all - of the higher level abstractions were explicitly designed not to worsen performance compared to low level code. And in my opinion Python is so much easier to use than C++ because it values simplicity and consistency more than efficiency.

For example the general loop constructions in Python which are possible because of nice generators and the wonderfully straightforward `yield` construction are unacceptable in C++ as they lack the flexibility to be as efficient as possible in every case.

The advantage of dynamic typing only becomes apparent in a third argumentative step; when you try build a language with consistent and efficient abstraction and you end up with something like Haskell whose type system complexity is huge entry barrier. That's why I think dynamic typing is good for Python.

DerpDerpDerp• 12 years ago

I find the Haskell type system much easier than the Python type system.

I'd argue that Haskell actually has a pedagogy problem, because many of its proponents are academics or mathematicians, who are comfortable with that kind of language. Talking about monads, functors, and arrows is a very natural activity for them, and clarifies rather than complicates the subject. However, you don't really have to understand any of that to get started in Haskell, and much of the blogging community has (I think wrongly) focused on explaining advanced concepts rather than making easy introductions.

You don't have to deal with monads any more than you have to deal with Python's OO behavior - which is to say, for quite a while.

I'd also argue that once you take in to account the sometime strange OO implementation of Python, and that Haskell has type inference for most things, Haskell is easier to understand the high level concepts in. Typeclasses and higher order functions (functions which act on functions) provide a very neat way to substitute in different types to your algorithm without having to change the whole thing, and don't even delve in to the complicated world of functors and monads.

sgt1012• 12 years ago

In my land we call this "julia"

shocks• 12 years ago

Python4! More sharding! :D

lispm9• 12 years ago

Modern type systems tend to be complicated and tend to hinder incremental development.

It wouldn't make Python easier to use. Just the opposite.

girvo2• 12 years ago

Whoah, hold on there, I disagree entirely. Modern optional type systems are great for incremental development, as I can ignore them for the most part in my code when rapidly iterating, but then when my APIs are starting to solidify, bring in some proper guarantees about my code's correctness. I've used Hack and TypeScript in production, and while they're no Haskell in terms of "moderness" of the type system, they're both quite nice.

mrfusion2• 12 years ago

While everyone is on the subject, I thought I'd mention some weird behavior I saw today.

I just switched my program from using a defaultdict to a regular dict.

I.e., from defaultdict(lambda:'NA') to regular dict using get(val, 'NA') for access.

And I got a something like a 100x speedup. It runs in two minutes instead of two hours. I had no idea a defaultdict would be so much slower.

Unless there's something funny going on in my program and it's unusual behavior.

zo13• 12 years ago

The docs for the defaultdict are here: https://docs.python.org/2/library/collections.html#collectio...

And they pretty much say that there is only one method that's been overridden from the normal dict class. And all it does is it executes the anonymous method (lamda) you supplied instead of returning the default value you pass in.

Also, this depends on your usage, and what you have in the lambda expression. I'm curious about your code, care to paste/link some of it for us?

cefstat• 12 years ago

I would guess that the code tries to get the value for keys that do not exist in the defaultdict. Well, if the key does not exist then it is being added with the default value 'NA'. So in this way you can end up with a huge dictionary where most of the values are just 'NA'.

cynwoody• 12 years ago

If you are predominately adding entries to a dictionary, the standard dict will be faster.

Where defaultdict shines is the case where you hit an entry a bunch of times, but you'd like to automate initializing an entry the first time it is hit.

The most common example is probably the frequency distribution, where the frequency needs to start out zero and be incremented each time a key is seen. Using int or lambda:0 as defaultdict's argument works fine for the simple case. If you want to tabulate more than just the count, e.g. a count and one or more sums, you can pass a constructor that produces an object with an update method, to which you pass whatever your key represents.

Simple microbenchmark: http://pastebin.com/vkacByzp

It appears that defaultdict saves time as well as code for the normal use case.

PythonicAlpha3• 12 years ago

Yes, Python is slower in execution than some other languages, but:

   ... efficient use of development time ...

That is the reason, why Python counts (not only references). Python has many very good libraries, is a good OOP language, easy to learn, but still very, very powerful. You can express in Python some things in a single line, where you need hundreds of lines in C++ or other languages.

The few percent of running speed that you might loose, are neglect-able in most cases against the win in development speed.

In many applications you don't need the full CPU power, but often times you are hindered by e.g. the disk speed or other factors ... and than you don't lose anything when you are a little bit slower in some minor tasks.

zo13• 12 years ago

And if you really need to have a piece of your code execute really quickly, you can just make C extension that python can easily invoke.

zmmmmm4• 12 years ago

Python's support for this is awesome, but there is a gap: you lost cross platform. You now have to figure out how to make it compile on every platform that anybody could every possibly want to run it on, including ones not yet invented in the future ... Jython / Java (or other JVM languages) are quite a nice option in that space.

nly6• 12 years ago

You can express in Python some things in a single line, where you need hundreds of lines in C++ or other languages.

citation needed.

PythonicAlpha3• 12 years ago

I have none, it is my personal experience, since I programmed in C++ (and other languages) before. So cite me, if necessary.

Borogove• 12 years ago

Example: x = {'foo':34,'bar':[1,2,3],'baz':'quux'}

The headers alone for STL maps are hundreds of LOC.

rch• 12 years ago

Python ends up being an extremely efficient language for the overall task of doing science with code.

This is pretty close to how I characterize my time, 'doing X with code', and Python yields great returns in these terms.

VeejayRampay• 12 years ago

Python (and Ruby for that matter) are slow because there are no billion-dollar companies stuck with an initial choice of language that impedes their ability to grow. PHP and Javascript used to be extremely slow and now after several dozens of millions thrown at JIT, rewrites, forks and redesigns they're starting to get much much faster.

hyperbovine• 12 years ago

Not so. Google uses Python extensively in-house (it's one of the four "blessed" languages) and, in fact, employed GVR until he was recently hired away by Dropbox--another billion-dollar company which relies heavily on Python. At one point Google even spearheaded an ambitious effort (https://code.google.com/p/unladen-swallow/) to make CPython much faster. It failed.

At the point where even Google can't make it happen, it really starts to look like Python performance is limited at some very fundamental level to what we see today. Personally I think this is fine. I use Python for everything day-to-day and offloading the intensive stuff to a C extension (a la Numpy) works just great. There are very few instances where I find myself wishing Python was faster.

ihnorton2• 12 years ago

Unladen Swallow started as an intership project and didn't get very much support at Google [1]. When US started (~2009), Google had been writing their core, high-performance stuff in Java and C++ for many years already so there was no internal or existential need to make Python faster.

[1] http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospect...

dragonwriter4• 12 years ago

At one point Google even spearheaded an ambitious effort (https://code.google.com/p/unladen-swallow/) to make CPython much faster. It failed.

The difference between Unladen Swallow and V8 is that while V8 was "make JavaScript fast on the workloads we care about by any means necessary", Unladen Swallow was "make CPython fast without disturbing the implementation's interface to native extensions". A V8-style approach to speeding up Python might well be practical even if a project with Unladen Swallow's constraints to using, and preserving the same relationship to extensions, was not.

At the point where even Google can't make it happen, it really starts to look like Python performance is limited at some very fundamental level to what we see today.

For the reasons above, "Google can't make it happen" isn't really a good description. Google choose to try with constraints it didn't apply to JavaScript, because for their purposes with Python -- unlike their purposes with JavaScript -- if they were going to go with an unconstrained approach, then they were quite happy tossing the language aside. OTOH, with V8, running actual JavaScript was important but existing external modules called from JavaScript weren't a constraint, so the interpreter had fewer constraints than with Unladen Swallow, and making the language faster (rather than getting something faster, but not necessarily keeping the same language if it made anything else more difficult) was a higher priority.

So V8 succeeding while Unladen Swallow fails isn't necessarily a sign that making a fast Python interpreter is harder than making a fast JavaScript interpreter -- making a fast JS interpreter (language non-negotiable) was a priority for Google, making Python faster if it could be done was a nice-to-have that wasn't worthwhile if it doing it in Python was disruptive enough that they wouldn't be able to leverage their existing library of stuff-built-to-interface-with-CPython without additional effort. The efforts weren't parallel, and the results aren't comparable.

vertex-four• 12 years ago

I think the point is that companies that use Python tend to be able to switch out to other languages where they need speed very easily, where it makes sense; for example, a lot of Python developers got very excited about Go, and now there's mostly-Python apps with certain functionality written in Go dotted about the place. The idea of calling out to services to do things is decidedly normal in Python.

PHP companies tend to have more of an issue with this, for various reasons. PHP apps can suffer from the "big ball of muck" issue quite easily, where there's not nearly enough abstraction to allow for parts of the code to be written in other languages. Such an architecture would also require additional deployment steps, vs PHP's "copy everything to the right place", and there's a lot of PHP devs who, while rather good at PHP, are quite resistant to new languages.

njharman2• 12 years ago

PyPy, Cython are examples of similar examples for Python.

Also, extension modules, Pillow, Numpy, Scipy, Pandas greatly reduce need to make Python it self faster.

amit_m• 12 years ago

The bigger picture is that CPython's core team simply does not care too much about performance. Performance has never been a fundamental requirement, but merely an afterthought.

The biggest reminder of this was Python 3, which for me was a complete disappointment. They could have limited python's super-dynamic behavior (e.g. changing builtin functions, patching classes on the fly, etc.) or made them optional. They could've added optional typing annotations a la Cython. Or even changing the builtins and language syntax to allow more inplace operations and preallocations, so that temporary results wouldn't have to be allocated on the heap over and over again. All of these changes would have made python faster and more JIT-able. None of these things happened. Performance-wise, python 3 is no step forward.

Python+Cython is still a powerful combination, but eventually Julia or similar languages will eat python's lunch with respect to scientific computing.

GFK_of_xmaspast2• 12 years ago

I think if python3 had made major performance improvements (not to mention the GIL) there wouldn't be nearly as many 2.7 holdouts.

ris• 12 years ago

And it still wouldn't be done.

est• 12 years ago

Yup. the HUGE "CPython is only reference implementation" ego

walshemj• 12 years ago

Not for pure performance Fortran still seems to be king for that type of scientific computing.

dmoney• 12 years ago

Related: "Python is only slow if you use it wrong" http://apenwarr.ca/diary/2011-10-pycodeconf-apenwarr.pdf [pdf]

Why Python is Slow: Looking Under the Hood

Related Stories