Performance comment (oddity with set.update())
michael.hudson at canonical.com
Wed Apr 23 05:58:09 BST 2008
Robert Collins wrote:
> On Wed, 2008-04-23 at 06:38 +0200, Torsten Bronger wrote:
>> Robert Collins writes:
>>> On Tue, 2008-04-22 at 16:49 -0500, John Arbash Meinel wrote:
>>>> I was just debugging some performance issues, and I came across
>>>> something funny.
>>>> Specifically, calling 'set.update()' with a generator that
>>>> returns nothing is slower than building it into a list and then
>>> I think this is worth filing a python bug on, so that the python
>>> devs are aware of it.
>> I think the actual benefit of a generator is its reduced memory
>> consumption rather than higher speed. Apparently, building a
>> generator has slightly higher fixed costs. Getting the next element
>> is almost as costly for the generator as for the list (while
>> building it), so their performances behave asymptotically for many
> Thats orthogonal though.
> We have a generator always. If we consume it with a list comprehension,
> it is faster than if we consume it via passing to x.update(). The latter
> example here does more work, but more quickly. This suggests a bug in
> $ python -m timeit -s 'x = set(range(10000))' 'x.update(y for y in )'
> 1000000 loops, best of 3: 0.837 usec per loop
> $ python -m timeit -s 'x = set(range(10000))' 'x.update([y for y in
> 1000000 loops, best of 3: 0.462 usec per loop
Er, no, because list comprehensions do not use generator comprehensions
under the hood.
More information about the bazaar