Performance comment (oddity with set.update())

[Robert Collins]

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


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080423/0465170b/attachment.pgp