Native Code vs. Python code for modules

koblas koblas at gmail.com
Wed Jul 30 05:56:31 CEST 2008


Ruby has been getting pummeled for the last year or more on the
performance subject.  They've been working hard at improving it.  From
my arm chair perspective Python is sitting on it's laurels and not
taking this as seriously as it probably should.  In general it's
possible to make many comments that swirl around religion and
approach, one of the things that I've noticed is that wile Python has
a much more disciplined developer community they're not using this for
the greater good.

Specifically, in looking at a benchmark that was posted, python was an
order of magnitude (20 secs vs. 1 sec) slower than ruby.  In
investigating the performance bottleneck is the random module.  This
got me to think, why does python have "pickle" and "cPickle"?  Comes
down to lowest common denominator, or the inability for somebody to
write an optimized package that can mimic a python package.

To that end why would somebody write big try catch blocks to see if
modules exist and if they exist alias their names.  Wouldn't it be
better if there was a way that if I have an "interface compatible"
native (aka C) module that has better performance that there could be
a way that python would give it preference.

e.g.

  import random(version=1.2, lang=c)
or
  import random(version=1.2, lang=py)   # use the python version by
default
or
  import random     #  use the latest version in the "fastest" code (C
given preference)

where there could be a nice set of "standard" key value pairs that
could provide addtional hints as to what language and version of a
library was to be used.



More information about the Python-list mailing list