all() is slow?
OKB (not okblacke)
brenNOSPAMbarn at NObrenSPAMbarn.net
Mon Nov 7 16:00:53 EST 2011
I noticed this (Python 2.6.5 on Windows XP):
>>> import random, timeit
>>> def myAll(x):
... for a in x:
... if a not in (True, False):
... return False
... return True
>>> x = [random.choice([True, False]) for a in xrange(0, 5000000)]
>>> timeit.timeit('myAll(x)', 'from __main__ import myAll, x',
number=10)
0: 9.7685158309226452
>>> timeit.timeit('all(a in (True, False) for a in x)', 'from __main__
import x', number=10)
1: 12.348196768024984
>>> x = [random.randint(0,100) for a in xrange(0, 5000000)]
>>> def myAll(x):
... for a in x:
... if not a <= 100:
... return False
... return True
>>> timeit.timeit('myAll(x)', 'from __main__ import myAll, x',
number=10)
4: 2.8248207523582209
>>> timeit.timeit('all(a <= 100 for a in x)', 'gc.enable(); from
__main__ import x', number=10)
5: 4.6433557896324942
What is the point of the all() function being a builtin if it's
slower than writing a function to do the check myself?
--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown
More information about the Python-list
mailing list