Patches item #1442927, was opened at 2006-03-04 01:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442927&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: PyLong_FromString optimization Initial Comment: The current implementation of PyLong_FromString in Python 2.5 uses muladd1 to add each digit of the input string into the final number. Because muladd1 creates a new long to hold the result on every call, an intermediate long object is created/destroyed for each digit in the input string. This patch improves on the current implementation of PyLong_FromString in 3 main ways: 1. Creates and manipulates (in-place) a single long object to hold the result, skipping the creation of all those intermediate long objects. 2. Multiple digits from the input string are consolidated into a single long digit before adding them into the long integer object. This greatly reduces the number of "multiply/add" cycles required to push all the digits into the long object. 3. Three chunks of code like "if (ch <= '9') k = ch - '0'" in longobject.c are replaced by a digit value lookup vector. I'm not irreversibly stuck on this idea; it doesn't measurably add to performance, but it just seems (to me, anyway) to make the code in long_from_binary_base and PyLong_FromString a little less cluttered. This is the same lookup table from patch 1335972 (an optimization for int()). I expect if both patches get accepted it would be best to make them both reference a single instance of this table; if it looks like that's what will happen I'll tweak one or both patches as necessary. My cheezy test results (included in the attached file in an OpenOffice spreadsheet) show that the patch makes long() about 50% faster than the existing implementation for decimal input strings of about 10 characters. Longer input strings show even better performance improvement, leveling off around 3x faster for very long strings. This patch passes regression tests on my machine (WinXP, Visual C++ .net Standard 2003). I plan to try out the tests on my Linux box this weekend just to make sure the performance boost still remains when Python gets compiled by a C compiler that isn't neutered (standard .net 2003 doesn't appear to allow any optimizations). The test and test data generation scripts I used for this performance comparison are included in the attached zip file. At the moment I don't have any added tests; if somebody can suggest some things that ought to be tested I'll gladly write some tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442927&group_id=5470 _______________________________________________ Patches mailing list [email protected] http://mail.python.org/mailman/listinfo/patches
