| msg68947 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-06-29 11:38 |
| The following says it all: >>> 1+1 is 2 True >>> int('2') is 2 False >>> int(b'2') is 2 False |
|
|
| msg68950 - (view) |
Author: Benjamin Peterson (benjamin.peterson) * |
Date: 2008-06-29 13:51 |
| I suspect this is because of the transition from PyInt to PyLong: Python 2.6b1+ (trunk:64580M, Jun 28 2008, 18:04:04) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> int('2') is 2 True >>> long('2') is 2 False |
|
|
| msg68960 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2008-06-29 17:43 |
| For the old int type, implementing this was trivial, as the conversion converted into a C long, then called PyInt_FromLong. For long, it's much more tricky, as no C type can be used to store the intermediate result. So instead, PyLong_FromString already allocates a sufficiently-sized long object (based on the number of digits of the input string), and then fills that object. Depending on what precisely the complaint of this report is about, one solution could be to check after the conversion whether the result has only one digit, and if so, whether it is a small integer, and if so, convert it to a long, discard it, and use PyLong_FromLong. If the complaint is that it unnecessarily allocates memory in the first place, I don't think anything should be done about that - the allocation is really necessary. In any case, I think PyLong_FromString should also call long_normalize before returning the result. |
|
|
| msg68968 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2008-06-29 21:17 |
| Le dimanche 29 juin 2008 à 17:43 +0000, Martin v. Löwis a écrit : > For long, it's much more tricky, as no C type can be used to store the > intermediate result. So instead, PyLong_FromString already allocates a > sufficiently-sized long object (based on the number of digits of the > input string), and then fills that object. > > Depending on what precisely the complaint of this report is about, one > solution could be to check after the conversion whether the result has > only one digit, and if so, whether it is a small integer, and if so, > convert it to a long, discard it, and use PyLong_FromLong. > > If the complaint is that it unnecessarily allocates memory in the first > place, I don't think anything should be done about that - the allocation > is really necessary. The bug entry is just for pointing out a missed optimization opportunity. The first mentioned solution would already be an improvement, although of course it would even be better to skip the intermediary allocation altogether. |
|
|
| msg68972 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2008-06-29 21:45 |
| > The bug entry is just for pointing out a missed optimization > opportunity. The first mentioned solution would already be an > improvement, although of course it would even be better to skip the > intermediary allocation altogether. Can you propose an implementation strategy that doesn't create the object, yet still avoids duplication of large chunks of code? |
|
|
| msg68973 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2008-06-29 22:23 |
| Le dimanche 29 juin 2008 à 21:52 +0000, Martin v. Löwis a écrit : > Can you propose an implementation strategy that doesn't create the > object, yet still avoids duplication of large chunks of code? If by "duplicating large chunks of code", you mean creating a separate code path for when the calculated number of digits necessary to hold the int is equal to 1, then I don't have an implementation strategy. I was going to say that creating and then immedietaly releasing a long should not be very costly since longs have a freelist, but then I checked and there is no freelist :-) (although there is a patch to add one in #2013) Anyway, the benefit IMO isn't in speeding up the conversion but in avoiding to store new objects in memory when we can re-use the existing singletons. |
|
|
| msg68989 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2008-06-30 04:07 |
| This is now fixed in r64596. |
|
|
| msg178224 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2012-12-26 15:27 |
| Should it be backported to 2.7? |
|
|
| msg178233 - (view) |
Author: Benjamin Peterson (benjamin.peterson) * |
Date: 2012-12-26 16:02 |
| It's only an optimization, so no. |
|
|