Message118120
> Maybe we could consider adding an extra field to a PyLong giving its
> 'small_int' value for small values, and some flag value for non-small
> longs. An extra field wouldn't actually enlarge the size of a PyLong
> for small values---on a 64-bit machine, a value like 23L takes 28
> bytes, for which 32 bytes will actually be allocated (since Python
> always allocates in multiples of 8 bytes, I believe).
I actually had a patch for that. It declared a ob_digit[2] array instead
of ob_digit[1], and ob_digit[1] contained the small int. But the patch
still used the pointer comparison approach for PyLong_IS_SMALL_INT,
because I think it's faster (just two comparisons). So there didn't seem
to much point.
Also, the pointer addition trick for addition (see BINARY_ADD) is
probably faster than the more intuitive method. |
|
Date |
User |
Action |
Args |
2010-10-07 16:23:48 | pitrou | set | recipients:
+ pitrou, rhettinger, aahz, amaury.forgeotdarc, mark.dickinson, stutzbach, Aahz |
2010-10-07 16:23:46 | pitrou | link | issue10044 messages |
2010-10-07 16:23:46 | pitrou | create | |
|