Van Rossum: Python Not Too Slow

snydeq writes "Python creator Guido van Rossum discusses the prospects and criticisms of Python, noting that critics of Python performance should supplement with C/C++ rather than re-engineering Python apps into a faster language. 'At some point, you end up with one little piece of your system, as a whole, where you end up spending all your time. If you write that just as a sort of simple-minded Python loop, at some point you will see that that is the bottleneck in your system. It is usually much more effective to take that one piece and replace that one function or module with a little bit of code you wrote in C or C++ rather than rewriting your entire system in a faster language, because for most of what you're doing, the speed of the language is irrelevant.'"

Comments

007087

[Anonymous Coward]

Title is kinda silly.. as the basic referenced statement is that in some cases python _is_ too slow but that one can work around that using hacks (or a language agnostic component oriented architecture).

As for:

You said that if you trust your compiler to find all the bugs in your program, you've not been doing software development for very long.

It’s not about finding all the bugs, or even many of them. It’s about another layer where a potential bug can be caught. Runtime bugs are the worst kind as they can sit dormant for a while if in a rarely traveled branch. The more checking that can be done at the compile level, the better (imo).

Personally my biggest complaint about python wasn’t on the list: A lot of the (common) libraries out there are poorly documented, inconsistent, buggy, or incomplete.

As a Gentoo user, the python 2/3 thing is also especially annoying. Obviously this isn’t really python’s fault.. but it still gives me a bad taste about python.

That said, this was a great article.. short, to the point, and the answers were pretty good!

Re:007087

[Pieroxy]

And to add to that:

Python Not Too Slow

True. It's not too slow. It's just not fast enough.

Re:007087

[Anonymous Coward]

This thread is idiocy. The point is, you can write the code in python several times in the same amount of time it takes to write it in C or C++. So if you then spend a fraction of that to optimize it, you write a very small portions in C/C++, you still wind up WAAAAY ahead.

These people come from a place where they understand the value of coders all that it entails. A better question is, where do you come from that you don't have to deal with the reality of programming in the real world?

Re:007087

[Anonymous Coward]

Python, apart from the inconsistent standard of the libraries that the GP mentioned, is brilliant for the 'glue code' that holds small to medium sized programs together. Ruby may have the edge for organising larger programs.

Rewriting a relatively small Python program in C++, one that does a fair bit of file handling, string chopping about etc, can make it into a relatively large program. Doing it in C is asking for pointer problems. I've been programming in C from before C++ existed, C++ since then and Python for about 5 years.

I am quite capable of writing the glue code successfully in any of the languages, but to do it efficiently I'd choose to do exactly as TFA says - write the main bulk of the code in Python( (or Ruby, or some other higher level language), then measure it to find the real slow bits (you wouldn't optimise until you have measured where the problems REALLY are, would you?) and rewrite just those bits in a lower level, faster language.

Of course, once you see where the speed issue lies, it's just as likely you can find an algorithmic improvement that fixes it 'enough' anyway...

Re:007087

[nedlohs]

Because it's significantly faster in terms of development time, or in terms of cost (having the less skilled, cheaper programmers work on it).

It's always been a case of write the critical stuff in C/C++. That's why languages like python and perl make doing so so simple.

Re:007087

[Anonymous Coward]

Also most people don't realize these were the same arguements given back in the 80s for writing stuff in assembly instead of C, and given that people have moved on to C++ since with the same things being said 'If it's too slow in C++ then optimize that routine in C', I would say this explanation is correct... ASSUMING python offers good enough profiling capabilities to pinpoint hotspots in the code so that you CAN optimize them away.

That said as the GGGP stated, gentoo's usage of python in a somewhat slow and half assed manner is frustrating (but if you compare it to ANY rpm based distro it's still faster than heck. Be it a 200 mhz or 3ghz processor. Most of the speed issues seem to be pertaining to sleep states rather than actual code anyways).

Re:007087

[tomhath]

as the basic referenced statement is that in some cases python _is_ too slow but that one can work around that using hacks

You completely missed what he said, which is "use the best tool for the job".

Most apps can be written much more quickly in Python than C/C++. If they perform adequately you're done. If there are slow spots, use an extension (it's not a hack) to optimize that tiny part of the app. This has been SOP since compiled languages were first invented; we used to write that last 5% of the app in Assembler. But obviously using C/C++ is more productive than Assembler and usually fast enough, just as using Python is more productive than C/C++ and usually fast enough.

Re:007087

[lgw]

The point is, you can write the code in python several times in the same amount of time it takes to write it in C or C++. So if you then spend a fraction of that to optimize it, you write a very small portions in C/C++, you still wind up WAAAAY ahead.

I have to disagree with that, a bit. C and old-style C++ has a lot of boilerplate allocate/release stuff going on, and yes that really slows you down making sure you got it right. But modern C++ RAII-style auto-everything code isn't like that. I find modern-style C++ and Java equivalent in the time it takes to solve the actual problem.

Python is sometimes faster to write in. If you're doing a lot of parsing, for example, it's great. If the total size of your Python codebase remains small, that really helps. But once you start writing very formal Python where the type of every argument is declared in comments, and error handling being done with exacting precision and logging, and so on, you might as well be writing in C++ or Java.

It's really not so much the language that makes adding code to a large code base slow! It's the need to obsess over geting the details of your thought process recorded in the code once you pass the point that any one person could possibly understand the whole codebase, or it's old enough that the original authors have all left.

Wrting code for small projects is what's (potentially) fast - and Python is great for realizing that potential.

Re:007087

[Terrasque]

Some stuff still remains performance sensitive enough that people will go to the trouble of optimizing it at a lower level.

And the other side of that coin, is of course, that most stuff is not performance sensitive enough to go to the trouble of optimizing it at a lower level.

Hence what Guido is saying. You can do that "most stuff" part in python, and then write that "some stuff" part as a C module. You can then use that module from python. Thus you get the benefit of both languages.

Re:007087

[madprof]

I'm always wary of people who say a language "sucks". Each language was designed the way it as for certain reasons. You may not agree with those reasons but they are there.
As it turns out I enjoy using Python quite a bit and it helps me get my work done nice and quickly, which mainly involves web code and associated sales processing. I could sit there and worry about what it can't do but what it can do is just fine.

Obviously the bash comparison is nonsensical. Bash is hardly the same kind of language as Python and I think you know that.

Re:007087

[GmExtremacy]

You don't need a CS degree to program in Python.

This is true of any language. Degrees don't equal knowledge or experience.

Agreed.

[Anonymous Coward]

Now that that is settled we can get back to the real problem with python: Type errors.

Kinda digging Python

[XxtraLarGe]

I'm signed up for the CS101 course @ Udacity, and I was surprised they were using Python for the course. It does seem a bit weird using whitespace for blocks, especially when you're used to writing stuff like
if(a > 0) { return a + 1; } else { return a -1; }
for the simple stuff. I do really like things like being able to return multiple values from a procedure, etc., but Python seems more useful for rapid prototyping rather than anything else.

usually?

[v1]

It is usually much more effective to take that one piece and replace that one function or module with a little bit of code you wrote in C or C++ rather than rewriting your entire system in a faster language, because for most of what you're doing, the speed of the language is irrelevant.'"

I have a lot of experience in code optimization, and I would dispute this generalization. "often" is a lot more realistic than "usually". The most common thing I see is where one particular segment of an operation is coded by someone that doesn't understand their O's and is doing something like multilevel lookup loops instead of a hash table. Fundamental mistakes in algorithm choice are the biggest "HERE is the biggest problem" issues I find.

Once you're past the stupid implementation mistakes, it goes just slightly in favor of "it's a little bit of everything" land. Something running significantly slower in one language than another often boils down to the coder not understanding how to make things scale in the chosen language. I can make C move slower than BASIC if I want to. Sometimes it's just knowing how the compiler is going to react to your structures. Little things like "roll up the loops when coding in VB" can produce an order or two of magnitude in speed improvement, and if you don't realize this you may think you're comparing identical implementations when you're not. "this language sucks!" often translates into "I don't know how to do it so it runs fast!"

My last project was reduced from 23 hrs per run to 21 minutes by a small but complex change in implementation. From there, getting it down to 4 minutes required a LOT of little changes all over the place, to nickel-and-dime it down. I'll trade you my "guy that knows how to recode it in C" for your "guy that knows how to code, and REALLY knows his compiler" any day.

Re:Logically Logical Logic

[Cogita]

Ahh -- yes, I see, so I should write my Apps in Python, except where they need to be rewritten in C/C++ because that will run faster than when written in Python, but Python is not slow when you rewrite portions -- so don't rewrite in a faster language because Pyton is fast enough.

Alrighty then.

Essentially yes, that's it exactly. It's a lot simpler to write a 5000 lines of python and 300 lines of C than it is to write 20,000+ lines of C. Plus Python manages most of the memory management for you so you have less chance of memory leaks. I would argue that the reduction in bugs memory bugs and more maintainable code would justify saying that one should use two languages in this case. It's not a matter of which is better overall, it's that python is easier to read, whereas C is faster. Use both where their benefits are most powerful.

Static vs. Dynamic Typing

[Teckla]

I was a little bit disappointed by Guido's response regarding static vs. dynamic typing:

InfoWorld: You talked about the arguments for and against dynamic typing. You said that if you trust your compiler to find all the bugs in your program, you've not been doing software development for very long. So you're satisfied with Python being dynamic?

Van Rossum: Absolutely. The basic philosophy of the language is not going to change. I don't see Python suddenly growing a static subdivision or small features in that direction.

Proponents of static typing do not claim that compilers, combined with languages that use static typing, will find all the bugs in your program. This is nothing more than Infoworld erecting a straw man and Guido knocking it down.

However, static typing does make a huge number of potential errors stick out like a sore thumb (the compiler will refuse to compile the code, and will emit appropriate error messages).

Some people (rightfully) argue that dynamic typing makes for shorter, prettier, easier code.

Some of us believe the primary concern should be correctness, and that shorter, prettier, easier code are secondary concerns -- almost always. People should think about this every time their computer crashes, or an application crashes, or something is acting up and needs to be rebooted, or they get a virus through no fault of their own, or their data gets corrupted.

Will users be thinking, "Gosh, this sucks, but I'm sure glad the programmer used a dynamic language, because it made it easier on him (the programmer)."? No, they'll be thinking, "Damn buggy programs! I just lost X (hours,minutes,seconds) of work, and now I'm frustrated!" Programming languages are a means to an end, not an end in itself. Don't be a self centered developer: the fruits of your labor are for users, not so you can write the code equivalent of poetry.

Not to mention, statically typed languages allow for easy refactoring possibilities that make it possible to fix all sorts of serious issues, including architectural ones, with reasonable effort expended. Dynamic languages, while they have made some progress in the area of refactoring, are really in the dark ages here.

I know dynamically typed programming languages are the hotness right now, and I'm sure my opinion will be hammered relentlessly, but I do ask that if you disagree, don't mod me down, but instead, bring forth a reasonable argument for a different position. This should not be a popularity contest, where the loser is not heard, no matter what side the loser is on.

Re:world needs a better high performance language

[lgw]

As far as high performance languages go, we have:

FORTRAN: King of the performance hill, but so annoying to use that nobody really does outside some scientific circles.

C++: This is what everybody uses to write high performance applications, but it's a mess of special cases and annoying syntax and megabyte-long error messages from deeply nested templates.

We need a modern language, with things like functions as first class objects and introspection, but with the performance and "to-the-metal" nature of C++ when you care about designing for optimal cache efficiency and so on.

This is entirely true. What C++ does is excellent. The standard libraries are great - self-resizing arrays and sane strings at bare-metal speeds (if used with just a bit of skill). All the common algorithms . But the C baggage is really a problem.

There's a lot of syntax and just "tricks" that are needlessly complex becuase of the history. The learning curve is not just steep, but pointlessly steep. The level of control you get does not require the level of complexity thrown at you.

And the worst is - people still write C-style code in C++! Because C-style coding is obious in the language, and RAII is not, you still see people thinking exceptions are bad, and programming like it's 1989. Because template syntax is the worst macro langage ever, you don't dare use templates outside of seldom-changing library code.

All of the downsides of C++ are fixable with a from-scratch language with the exact same feature set, but no legacy syntax.