On Thu, Oct 14, 2021 at 11:15:52PM +1100, Chris Angelico wrote: > On Thu, Oct 14, 2021 at 11:03 PM Jeremiah Vivian > <nohackingofkrow...@gmail.com> wrote: > > > > Results are in (tested > > `next(iter(d))`/`next(iter(d.values())`/`next(iter(d.items())` and their > > `next(reverse())` counterparts): > > `*` / `/` implemented is 2x faster than `next(iter(d))`/`next(reversed(d))` > > `+` / `-` implemented is approximately 3x faster than > > `next(iter(d.values()))`/`next(reversed(d.values()))` > > `<<` / `>>` implemented is at least 4x faster than > > `next(iter(d.items()))`/`next(reversed(d.items()))` > > > > So, negligible benefits. Thanks for checking.
Be fair Chris :-) A 2x or 4x speed-up (even of a micro-benchmark) is not negligible. If someone managed a mere 20% or 30% speedup to next(), we would probably be more than happy to take it. A better way to put this is that while the speed benefit to one uncommon task is non-negligible, the cost to readability and comprehensibility is horrendous. This is premature optimization: there's no evidence that getting the first element of a dict is a common operation, let alone a bottleneck that needs optimising. Ultimately, for every millisecond in program runtime saved by using obscure operators for uncommon operations on dicts, we would probably cost a dozen programmers five or ten minutes in confusion while they try to decipher what on earth `mydict << 1` means. There are programming languages designed to be terse and even deliberately obfuscated, especially code-golfing languages. I'm glad Python is not one of them :-) -- Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/VATEHX2NA5K5SV2PVK7OTCGFK3LSNONQ/ Code of Conduct: http://python.org/psf/codeofconduct/
