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 rhettinger
Recipients amaury.forgeotdarc, collinwinter, eric.smith, mark.dickinson, pitrou, rhettinger, stutzbach, terry.reedy, tim.peters
Date 2010-11-30.22:22:06
SpamBayes Score 2.8974656e-11
Marked as misclassified No
Message-id <1291155728.19.0.316022899953.issue9915@psf.upfronthosting.co.za>
In-reply-to
Content
+1 on the basic idea of moving elements in the keys and values arrays at the same time thereby eliminating the fragmented memory overhead of the sortwrapper indirection.

I would like the patch to be restricted to just that change.  The other tweaks are not convincing (relying on compiler and processor specific optimizations that vary across platforms).  Instead, try to minimize the patch, making as few changes as possible to manipulation both arrays.  Also, try to follow the C style of the other code in the standard library -- the current patch has a different flavor to say the least ;-)

Ideally, the code will have the same look and feel as it does now (so that the Timsort remains recognizable to Tim ;-).  This code doesn't just need to run fast, it needs to serve as a readable model for anyone else trying to implement the algorithm.

If you still want the other tweaks, I recommend putting them in a separate patch afterwards and consider deferring them to 3.3.  It's a little late in the dev cycle to make lots of microscopic changes that may introduce a bug or unexpected behavior or perform weirdly on one of the less used platforms.
History
Date User Action Args
2010-11-30 22:22:08rhettingersetrecipients: + rhettinger, tim.peters, collinwinter, terry.reedy, amaury.forgeotdarc, mark.dickinson, pitrou, eric.smith, stutzbach
2010-11-30 22:22:08rhettingersetmessageid: <1291155728.19.0.316022899953.issue9915@psf.upfronthosting.co.za>
2010-11-30 22:22:06rhettingerlinkissue9915 messages
2010-11-30 22:22:06rhettingercreate