map vs. list-comprehension

[Sion Arrowsmith]

Exactly the same thing happened with Java.

I was under the impression that Python's logging module (like unittest)
was based on a common Java one, and it's complexity could be blamed on
that.

if you look at the libraries
that were in 1.1, they're very clean and simple (perhaps with the
exception of AWT). 1.2 added a load of stuff that was much less
well-designed (with the notable exception of the collections stuff, which
is beautiful)

There are very many adjectives I could (and have) used to describe
the Collection framework. "Beautiful" is not among them. I think
the closest I could manage is "baroque".

 

[Stelios Xanthakis]

jepp - faster, but still slower than the map.

1000000 iterations:
zip+list-comprehension: 8.1s
izip+list-comprehension: 7.5s
map: 7.0s

Strange. On 2.4.1 izip is the fastest.
The thing is that if you put benchmark code in global the
results are not fair as each variable access is a LOAD_GLOBAL
and costs a dictionary lookup. That can lead to wrong
results, like that 'try ... except ..' is faster than
'if i in ..'.

With this benchmak:

#--------------------------------------------------------
from itertools import izip
from time import time

def f1():
return map(lambda bb,ii,dd: bb+ii*dd,b,i,d)
def f2():
return [ bb+ii*dd for bb,ii,dd in zip(b,i,d) ]
def f3():
return [ bb+ii*dd for bb,ii,dd in izip(b,i,d) ]

def run(f, K):
t0 = time ()
for i in xrange (K):
f()
return time()-t0

T = 2000000

def BENCH(K):
global b, i, d
N = T/K
print "%i times tuples of size %i:" % (K,N)
b = tuple (range(0, -N, -1))
i = tuple (range(N))
d = tuple (N*[1])
for x, y in sorted ([(run (x1,K), y1) for x1, y1 in
((f1,'map'),(f2,'zip'),(f3,'izip'))]):
print '%s: %.2f' %(y,x),
print

BENCH(200000)
BENCH(20000)
BENCH(2000)
BENCH(200)
BENCH(20)
BENCH(1)
#--------------------------------------------------------

On 2.4.1 I get:

python zipmap.py
200000 times tuples of size 10:
izip: 1.32 zip: 1.50 map: 1.60
20000 times tuples of size 100:
izip: 1.00 zip: 1.14 map: 1.29
2000 times tuples of size 1000:
izip: 0.94 zip: 1.10 map: 1.28
200 times tuples of size 10000:
izip: 0.93 map: 1.29 zip: 1.51
20 times tuples of size 100000:
izip: 0.96 map: 1.31 zip: 2.28
1 times tuples of size 2000000:
izip: 0.96 map: 1.33 zip: 13.28



Stelios

 

[Scott David Daniels]

Look at what happened to C when it mutated into C++. In isolation, most of
the features of C++ seem like good ideas. Taken together, it's a huge
hairy mess that most people only understand increasingly larger subsets of.
Fred Brooks called it the second system syndrome.

If you read "The Design and Evolution of C++" by Stroustrupp, you can
see how most of current C++ is a direct result of its initial design
requirements, not an aglomeration of features, each of which is a "good
idea." I take from the resulting big hairy mess that the design goals
themselves are at fault for the big hairy mess.

--Scott David Daniels
(e-mail address removed)

 

[Roy Smith]

If you read "The Design and Evolution of C++" by Stroustrupp, you can
see how most of current C++ is a direct result of its initial design
requirements, not an aglomeration of features, each of which is a "good
idea." I take from the resulting big hairy mess that the design goals
themselves are at fault for the big hairy mess.

I havn't read the book, but, wasn't the whole STL dropped into place
quite late, long after the basic language design was done? There's a
fair amount of hair in the STL.

I thought exceptions and the myriad of cast operators were latecomers
to the party too. Or is it simply that some compilers didn't support
those features (or support them well) until recently?

I've heard some people say that one of the reasons C++ is such a mess
is because it had to retain backwards compatability with C. I don't
buy that. There's nothing in the miserably complex class inheritance,
polymorphism, access control, argument defaulting machinery that
harkens back to C. There's nothing about template error messages that
don't fit on a single screen that harkens back to C. About the only
major problem which I can see that traces to C is the memory
management.

 

[Tom Anderson]

I was under the impression that Python's logging module (like unittest)
was based on a common Java one, and it's complexity could be blamed on
that.

That would explain it. Who was responsible for this crime? I say we shoot
them and burn the bodies.

There are very many adjectives I could (and have) used to describe the
Collection framework. "Beautiful" is not among them. I think the closest
I could manage is "baroque".

Oh, i don't think it's really that bad. For java.

tom