
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/894331838b256412c95d54051ec46a1cb96f5... [2]: https://github.com/python/cpython/blob/894331838b256412c95d54051ec46a1cb96f5... [3]: https://github.com/python/cpython/blob/894331838b256412c95d54051ec46a1cb96f5... 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
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
range(100_000)]", number=10_000) 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/243KH6... Code of Conduct: http://python.org/psf/codeofconduct/
-- Antoine Rozo