> On Aug 29, 2019, at 06:40, Rhodri James <rho...@kynesim.co.uk> wrote: > > However, it sounds like what you really want is something I've often really > wanted to -- a way to get the compiler to pre-create "constant" objects for > me.
People often say they want this, but does anyone actually ever have a good reason for it? I was taken in by the lure of this idea myself—all those wasted frozenset constructor calls! (This was before the peephole optimizer understood frozensets.) Of course I hadn’t even bothered to construct the frozensets from tuples instead of lists, which should have been a hint that I was in premature optimization mode, and should have been the first thing I tried before going off the deep end. But hacking bytecode is fun, so I sat down and wrote a bytecode processor that let me replace any expression with a LOAD_CONST, much as the builtin optimizer does for things like simple arithmetic. It’s easy to hook it up to a decorator to call on a function, or to an import hook to call at module compile time. And then, finally, it’s time to benchmark and discover that it makes no difference. Stripping things down to something trivial enough to be tested… aha, I really was saving 13us, it’s just that 13us is not measurable in code that takes seconds to run. Maybe someone has a real use case where it matters. But I’ve never seen one. I tried to find good nails for my shiny new hammer and never found one, and eventually just stopped maintaining it. And then I revived it when I wrote my decimal literal hack (the predecessor to the more general user literal hack I linked earlier in the thread) back during the 2015 iteration of this discussion, but again couldn’t come up with a plausible example where those 2.3d pseudo-literals were measurably affecting performance and needed constifying; I don’t think I even bothered mentioning it in that thread. Also, even if you find a problem, it‘s almost always easy to work around today. If the constant is constructed inside a loop, just manually lift it out of the loop. If it’s in a function body, this is effectively the same problem as global or builtin lookups being too slow inside a function body, and can be solved the same way, with a keyword parameter with a default value. And if the Python community thinks that _sin=sin is good enough for the uncommon problem of lookups significantly affecting performance, surely of _vals=frozenset((1,2,3)) is also good enough for that far more uncommon problem, and therefore _limit=1e1000dec would also be good enough for the new but probably even more uncommon one. (Also, notice that the param default can be used with mutable values, it’s just up to you to make sure you don’t accidentally mutate them; an invisible compiler optimization couldn’t do that, at least not without something like Victor Stinner’s FAT guards.) For what it’s worth, I actually found my @constify decorator more readable than the param default, especially for global functions—but not nearly enough so that it’s worth using a hacky, CPython-specific module that I have to maintain across Python versions (and byteplay to byteplay3 to bytecode) and that nobody else is using. Or to propose for a builtin (or stdlib but magic) feature. What this all comes down to is that, despite my initial impression, I really don’t care whether Python thinks 1.23d is a constant value or not; I only care whether the human reader thinks it is one. Think about it this way: do you know off the top of your head whether (1, (2,3)) gets optimized to a const the same way (1,2) does in CPython? Has it ever occurred to you to check before I asked? And this is actually something that changed relatively recently. Why would someone who doesn’t even think about when tuples are constified want to talk about how to force Python to constify other types? Because even years of Python experience hasn’t cured us of premature-optimization-itis. _______________________________________________ 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/L53N6XRIQ7CL43B2R2ZVB3IIFHNK5XD2/ Code of Conduct: http://python.org/psf/codeofconduct/
