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 mark.dickinson
Recipients josh.r, mark.dickinson, pitrou, scoder, serhiy.storchaka, vstinner
Date 2014-05-04.09:34:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1399196069.29.0.0536756628818.issue21420@psf.upfronthosting.co.za>
In-reply-to
Content
Victor, can you demonstrate any cases of real code where this optimization makes a significant difference?

There are many, many tiny optimisations we *could* be making in Objects/longobject.c; each of those potential optimisations adds to the cost of maintaining the code, detracts from readability, and potentially even slows down the common cases fractionally.  In general, I think we should only be applying this sort of optimization when there's a clear benefit to real-world code.  I don't think this one crosses that line.

In the (I suspect rare) cases where a piece of real-world code is slowed down significantly due to a non-optimized 2**n, the code author still has the option of replacing that piece of code with 1<<n manually.  And in some cases, that's probably the wrong optimization anyway: an expression like `x * 2**n` would be better hand-optimized to `x << n`.

IOW, I'm -1 on making this change.
History
Date User Action Args
2014-05-04 09:34:29mark.dickinsonsetrecipients: + mark.dickinson, pitrou, scoder, vstinner, serhiy.storchaka, josh.r
2014-05-04 09:34:29mark.dickinsonsetmessageid: <1399196069.29.0.0536756628818.issue21420@psf.upfronthosting.co.za>
2014-05-04 09:34:29mark.dickinsonlinkissue21420 messages
2014-05-04 09:34:28mark.dickinsoncreate