
On Mon, Jan 17, 2022 at 3:50 AM Steven D'Aprano <steve@pearwood.info> wrote:
If you saw this code in a review:
t = tuple([1, 2, 3, 4, 5])
would you say "that is okay, because the name lookup is smaller than the cost of building the list"?
I wouldn't. I would change the code to `(1, 2, 3, 4, 5)`.
Of course, everyone would -- because tuple displays already exist. I'd suggest refactoring that code even if the compiler could completely optimize it away. Would you let: l = list([1, 2, 3, 4, 5]) pass code review either? even if there were no performance penalty? I wouldn't, because it's redundant, not because it's slower. Also that pattern is actually very common for types that aren't built-in (or even in the stdlib). It's always kind of bugged me that I need to write: arr = np.array([1, 2, 3, 4]) And I'm creating a list just so I can pass it to the array constructor. But in practice, it's not a performance problem at all. And in code in the wild, I'll bet numpy arrays are used orders of magnitude more than frozen sets ;-) Sometimes, now, the compiler *pessimizes* the construction of the frozen
set. See b.p.o #46393.
yup. Using a 'constant' frozenset is slower than 'constant' set, when doing not much else: In [29]: def setfun(): ...: s = {1, 3, 5, 2} ...: i = 3 ...: if i in s: ...: return 'yes' ...: In [30]: def fsetfun(): ...: s = frozenset((1, 3, 5, 2)) ...: i = 3 ...: if i in s: ...: return 'yes' ...: In [31]: %timeit setfun() 194 ns ± 10.6 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each) In [32]: %timeit fsetfun() 286 ns ± 2.72 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each) But: would you notice if that function did any real work? And I think we could call this one of the many micro-optimizations we have in Python: Don't use a frozenset as a constant when a regular set will do. So it comes down to how often frozen sets as constants are required. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython