Returning int instead of long from struct when possible for performance
Python ints are a heck of a lot faster to work with than Python longs and have the additional benefit that psyco <http:// psyco.sourceforge.net> can optimize the hell out of int but can't do anything at all for long. This is important because psyco is currently in pretty wide-spread use amongst people who need to squeeze every bit of performance out of their Python programs, and often yields 4x or better performance improvement in real-world tests. A more far reaching change would be to add a new PyInteger_From* API for code that doesn't care if long or int is returned, but I don't see much of a reason to go that far at this point since the rest of the standard library wouldn't benefit much. Unfortunately, this change to the struct module slightly alters the documented API for the following format codes: I, L, q, Q. Currently it is documented that those format codes will always return longs, regardless of their value. I've prototyped this change on the trunk (behind a currently undefined PY_USE_INT_WHEN_POSSIBLE macro). The standard library test suite passes with this enabled, but it would break any doctests in third party code that check the result of an unpack operation with one of those format codes. Given the interchangeability of int and long, I don't foresee any other complications with this change. Thoughts? -bob
[Bob Ippolito]
... Unfortunately, this change to the struct module slightly alters the documented API for the following format codes: I, L, q, Q. Currently it is documented that those format codes will always return longs, regardless of their value.
I view that more as having documented the CPython implementation du jour than as documenting the language. IOW, it was a doc bug <0.5 wink>.
I've prototyped this change on the trunk (behind a currently undefined PY_USE_INT_WHEN_POSSIBLE macro). The standard library test suite passes with this enabled, but it would break any doctests in third party code that check the result of an unpack operation with one of those format codes. Given the interchangeability of int and long, I don't foresee any other complications with this change.
Thoughts?
+1, and for 2.5. Even int() doesn't always return an int anymore, and it's just stupid to bear the burden of an unbounded long when it's not really needed. As to doctest breakage, I'm wholly unsympathetic to any doctest user except me, and I don't have any doctests that would break. So that's a total non-issue :-)
On 5/26/06, Tim Peters <tim.peters@gmail.com> wrote:
[Bob Ippolito]
Given the interchangeability of int and long, I don't foresee any other complications with this change.
Thoughts?
+1, and for 2.5. Even int() doesn't always return an int anymore, and it's just stupid to bear the burden of an unbounded long when it's not really needed.
Completely agreed. We've been unifying longs and integers for whole releases, I cannot imagine anyone not getting the hint. Ints and longs are the same thing, deal with it. Whether you get an int or a long for a particular value is a platform-dependant accident anyway (people seem to be ignoring 64-bit hardware all the time... I know Tim does :) -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Hi Bob, On Thu, May 25, 2006 at 10:58:21PM +0000, Bob Ippolito wrote:
Python ints are a heck of a lot faster to work with than Python longs and have the additional benefit that psyco <http:// psyco.sourceforge.net> can optimize the hell out of int but can't do anything at all for long.
Alternatively, someone could implement in Psyco longs that are known to fit in an int, and longs that are known to fit in an unsigned int, and longs that fit in a C long long, etc... Given a full range of long variants, it would be easier and faster to emulate a CPython behavior where the user-visible return type is consistent. So, as far as Psyco is concerned I'm -1 on this change. (I won't deny its speed and memory benefits to plain CPython, though.) Armin
participants (4)
-
Armin Rigo
-
Bob Ippolito
-
Thomas Wouters
-
Tim Peters