Performance comment (oddity with set.update())

[Michael Hudson]

Robert Collins wrote:
> On Wed, 2008-04-23 at 06:38 +0200, Torsten Bronger wrote:
>> Hallöchen!
>>
>> 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
>>>> updating.
>>> 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
>> iterations.
> 
> 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
> update().
> 
> $ 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.

Cheers,
mwh