This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Greg Price
Recipients Greg Price, jdemeyer, sir-sigurd
Date 2019-08-25.06:32:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1566714755.54.0.372843929228.issue37837@roundup.psfhosted.org>
In-reply-to
Content
Very interesting, thanks!

It looks like with LTO enabled, this optimization has no effect at all.

This change adds significant complexity, and it seems like the hoped-for payoff is entirely in terms of performance on rather narrowly-focused microbenchmarks.  In general I think that sets the bar rather high for making sure the performance gains are meaningful enough to justify the increase in complexity in the code.

In particular, I expect most anyone running Python and concerned with performance to be using LTO.  (It's standard in distro builds of Python, so that covers probably most users already.)  That means if the optimization doesn't do anything in the presence of LTO, it doesn't really count. ;-)

---

Now, I am surprised at the specifics of the result! I expected that LTO would probably pick up the equivalent optimization on its own, so that this change didn't have an effect. Instead, it looks like with LTO, this microbenchmark performs the same as it does without LTO *before* this change. That suggests that LTO may instead be blocking this optimization.

In that case, there may still be an opportunity: if you can work out why the change doesn't help under LTO, maybe you can find a way to make this optimization happen under LTO after all.
History
Date User Action Args
2019-08-25 06:32:35Greg Pricesetrecipients: + Greg Price, jdemeyer, sir-sigurd
2019-08-25 06:32:35Greg Pricesetmessageid: <1566714755.54.0.372843929228.issue37837@roundup.psfhosted.org>
2019-08-25 06:32:35Greg Pricelinkissue37837 messages
2019-08-25 06:32:35Greg Pricecreate