> I think the small time difference you noticed is only due to method lookup.

I believe it's a bit more than just the Python method lookup, but that makes some difference. Within the C-API, list += other uses list_inplace_concat [1]; whereas list.extend uses _PyList_Extend [2]. They both call list_extend [3], but they're not exactly equivalent. With the in-place operation, the intermediate results can be discarded right away. Also, at the bytecode level, += can use the STORE_FAST instruction to directly the push the result from the TOS to local var; whereas list.extend uses POP_TOP.

But I'll leave it at that, I don't want to focus much on performance; especially not with comparing list += other vs ls.extend(other). As mentioned elsewhere in the topic, performance isn't the goal of this PEP. I was mostly just curious if dict |= other would likely be very slightly faster than dict.update(other), and wanted some elaboration on where performance might be a mild concern.

[1]: https://github.com/python/cpython/blob/894331838b256412c95d54051ec46a1cb96f52e7/Objects/listobject.c#L996

[2]: https://github.com/python/cpython/blob/894331838b256412c95d54051ec46a1cb96f52e7/Objects/listobject.c#L990

[3]: https://github.com/python/cpython/blob/894331838b256412c95d54051ec46a1cb96f52e7/Objects/listobject.c#L996

On Tue, Dec 3, 2019 at 12:21 PM Antoine Rozo <antoine.rozo@gmail.com> wrote:

I think the small time difference you noticed is only due to method lookup.

Le mar. 3 déc. 2019 à 13:57, Kyle Stanley <aeros167@gmail.com> a écrit :
>
> > Actually there's no need to optimize the |= operator -- for strings we have to optimize += *because* strings are immutable, but for dicts we would define |= as essentially an alias for .update(), just like the relationship between += and .extend() for lists, and then no unnecessary objects would be created.
>
> Yeah that's why I noted that any form of optimization for the |= operator on dicts would not be the same as += is for strings. I wasn't actually sure of what form any potential optimization would take for the |= operator though. What exactly was the performance question/point in reference to? The question seemed to imply that there would be some minor performance detriment from using |=, but it's not clear to me as to when that would be a factor.
>
> > ## What about performance?
>
> > Performance is not the only objective when using Python. Switching to inplace operators (here |=) is a generally useful and well-known technique (it also applies to string and list concatenation, for example).
>
> Also with lists, I recall that using the += operator is very slightly faster than list.extend() in most situations:
>
> >>> ls_plus_eq = """\
> for i in range(1_000):
> ls += [x for x in range(10)]
> """
> >>> ls_extend = """\
> for i in range(1_000):
> ls.extend([x for x in range(10)])
> """
> >>> timeit.timeit(ls_plus_eq, setup="ls = []", number=10_000)
> 6.563132778996078
> >>> timeit.timeit(ls_extend, setup="ls = []", number=10_000)
> 6.695127692000824
> >>> timeit.timeit("ls+=other", setup="ls = []; other=[i for i in range(100_000)]", number=10_000)
> 4.400735091003298
> >>> timeit.timeit("ls.extend(other)", setup="ls = []; other=[i for i in range(100_000)]", number=10_000)
> 4.574331789997814
> >>> timeit.timeit("ls+=other", setup="ls = []; other=[i for i in range(100)]", number=10_000_000)
> 3.5332175369985634
> >>> timeit.timeit("ls.extend(other)", setup="ls = []; other=[i for i in range(100)]", number=10_000_000)
> 3.7756526679950184
>
> (Python 3.8)
>
> It seems to be a difference of only ~2-4% in most cases (~6-7% with the last set), but I find it interesting that += is barely faster. Of course, some of the above examples are fairly unrealistic, for most practical use cases they're essentially the same. I tend to prefer ls.extend() most of the time myself (the behavior is a bit more obvious). I'm mostly just curious if the difference between |= and dict.update() would end up being similar as far as performance goes, with |= having a negligible advantage over dict.update() in most situations.
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-leave@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/243KH67NWORPWGR75D3ZWRNGKUPRWG5F/
> Code of Conduct: http://python.org/psf/codeofconduct/

--
Antoine Rozo