One Python 2.1 idea

[Alex Martelli]

<rturpin at my-deja.com> wrote in message news:9237md$orm$1 at nnrp1.deja.com...
    [snip]
> scripting languages what location is to real estate. One of
> the nice things about list comprehensions is that it
> improves performance by abstracting an existing language
> mechanism.

Hi Russell, long time no see!  Unfortunately, the 'improves
performance' here is counterfactual.  There was a silly error
in my benchmark (I was timing the same function twice --
thanks to a kind correspondent for pointing this out!-), and
here it is in the correct form, augmented with a simple loop
solution as a reference point...:

import time

def withMap(inList):
    return map(lambda x: x+1, inList)

def withLC(inList):
    return [x+1 for x in inList]

def withLoop(inList):
    l = len(inList)
    result = [None]*l
    for i in range(l):
        result[i] = inList[i]+1
    return result

def stopWatch(function, N=100*1000):
    start = time.clock()
    function(range(N))
    stend = time.clock()
    return stend-start

print "Using map and lambda:     %f" % stopWatch(withMap)
print "Using list-comprehension: %f" % stopWatch(withLC)
print "Using a simple loop:      %f" % stopWatch(withLoop)

D:\PySym\cover>python spe.py
Using map and lambda:     0.891596
Using list-comprehension: 1.051381
Using a simple loop:      0.721732

D:\PySym\cover>python spe.py
Using map and lambda:     0.706179
Using list-comprehension: 1.005335
Using a simple loop:      0.706091

D:\PySym\cover>python spe.py
Using map and lambda:     0.817602
Using list-comprehension: 1.053890
Using a simple loop:      0.703723




So, the list comprehension in this case is SLOWER by over 10%
than the map-and-lambda.  If speed was indeed paramount, one
should thus eschew it -- counterintuitive, but I guess there must
be problems in the allocation/reallocation strategy of the list
comprehension, which appears to reallocate N times for N items
(while map allocates the resulting-list once, I think).

But note that a simple loop with preallocation of result is _at
least_ as fast as map, here -- indeed, it's the fastest approach.
If speed be all, then, avoiding advanced constructs may in some
cases prove the best approach!


Actually, for all-out speed in a higher-level language, Scheme
(with the stalin compiler) or Common Lisp probably cannot be
beat.  There ARE, after all, decades of Lisp experience and many
groups of clever people laboring away at getting such speed.
(If one is willing to forego dynamic typing, O'Caml or other
MLs may be contenders; Dylan may also be of interest; and
Smalltalk also has speedy implementations, if one will pay...).

I prefer Python because I do NOT prize speed in a higher-level
language above other factors -- great practicality at "playing
well with others", clarity, cleanness of syntax, great productivity.

If you do have another scale of values, Python may not be the
best choice for you at this time; specifically, if for some reason
the solutions MUST be single-language ones (you can't or
won't use a lower-level, faster language for that 10% or so of
your code that bottlenecks its speed).  I do not have any such
constraint, so Python + some tiny amount of C++ at the right places
(often already provided in the form of existing modules such
as Numeric, PIL, ...) is exactly right for my needs...


Alex