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 collinwinter, eric.smith, gawain, gregory.p.smith, mark.dickinson, vstinner
Date 2009-09-20.09:04:57
SpamBayes Score 3.2301276e-08
Marked as misclassified No
Message-id <1253437500.87.0.00868003068925.issue6713@psf.upfronthosting.co.za>
In-reply-to
Content
> I do think it would be unfortunately to not go a little further though -
> just because we can do better with little effort, we can save a few CPU
> cycles which means saving time, money and all of this can only be good
> for the planet.  ;-)

Gawain,

Programmer cycles matter too. :-)   Code clarity, especially in the Python 
core, is valued (at least by me) very highly---for all the usual reasons:  
readability, maintainability, fewer places for bugs to hide.  Verifying 
the correctness of the shorter version of int_to_decimal_string takes 
significantly less time, for me, than verifying the longer version.  Of 
course, that's probably partly because I wrote it, but I'd guess that it's 
still true for an independent viewer.

For example, Tim Peters has been heard to say that if he did this all over 
again, he probably wouldn't have added Karatsuba multplication:

http://mail.python.org/pipermail/python-dev/2008-November/083355.html

It's not easy deciding where to draw the line, but for me, this particular 
tiny speed gain (12.5% on a microbenchmark isn't really that significant) 
just isn't worth this particular (also tiny, admittedly) complexity gain.
History
Date User Action Args
2009-09-20 09:05:01mark.dickinsonsetrecipients: + mark.dickinson, collinwinter, gregory.p.smith, vstinner, eric.smith, gawain
2009-09-20 09:05:00mark.dickinsonsetmessageid: <1253437500.87.0.00868003068925.issue6713@psf.upfronthosting.co.za>
2009-09-20 09:04:59mark.dickinsonlinkissue6713 messages
2009-09-20 09:04:57mark.dickinsoncreate