Python Performance

[Markus Stenberg]

Skip Montanaro <skip at mojam.com> writes:
> I got a bit confused attributing this message.  I think we have too many
> Markus's running around loose... ;-)  I think I have the quoted text
> attributed correctly.  Apologies if not.

You had it reversed ;)

> Better yet, since the Python source code is available, you could prove it by
> speeding up the interpreter.  Many people have optimized different parts of
> Python over the lifetime of the software.  It's significantly faster than it
> was a couple years ago.

Being able to note a problem differs greatly from being able to _fix_ a
problem ;-) I've glanced thru it, and can't offhand find anything _very_
badly implemented that I could fix.

> I think one of the impediments to improving the speed of the language has
> been the dramatic performance improvement in hardware.  There's not a lot of
> incentive to pour lots of time into speeding up method calls when for a few
> hundred bucks you can simply drop in a faster processor, disk or networking
> card.

True.

>     Kohler> P.S. This might surface as one example for 'why scripting
>     Kohler> languages don't always cut it' in my master's thesis; if I have
>     Kohler> made some grievous error(s?), corrections are welcome.
> I don't recall anyone ever saying scripting languages would always cut it.

Scripting languages are offered as be-all end-all by many people, for some
reason. 

>     Kohler> P.P.S. Too bad Python doesn't have anything that creates _nice_
>     Kohler> code, like Stalin for Lisp ;-)
> There is a substantially shorter history to Python than to Lisp.  Give it
> time.  In addition, Lisp has been knocking around the academic world for
> 40-odd years.  With that many graduate students looking for a thesis topic,
> it was likely that some of those theses would focus on performance
> enhancement.

True; maybe in 30 years, eh?

> give-typewriters-to-enough-chimpanzees-and-you'll-get-Shakespeare-ly y'rs,

-Markus (Stenberg)