Serhiy Storchaka added the comment:
According to my and Larry's measurements [1] the distribution of created int's
by size during running Python tests is:
On 32-bit Linux:
int 42828741 13.40%
0 425353 0.99% 0.99%
1 21399290 49.96% 50.96%
2 10496856 24.51% 75.47%
3 4873346 11.38% 86.85%
4 1021563 2.39% 89.23%
5 1246444 2.91% 92.14%
6 733676 1.71% 93.85%
7 123074 0.29% 94.14%
8 139203 0.33% 94.47%
...
On 64-bit Linux:
int 47600237 13.53%
0 294964 0.62% 0.62%
1 36135772 75.92% 76.53%
2 4504046 9.46% 86.00%
3 2109837 4.43% 90.43%
4 1277995 2.68% 93.11%
5 542775 1.14% 94.25%
6 485451 1.02% 95.27%
...
86% of ints have size <= 3 on 32-bit and <= 2 on 64-bit. This is enough to
represent 32-bit integers (as in Python 2 int). I think we should support free
list not only for 1-digit ints, but at least up to 3 digit on 32-bit build and
up to 2 digits on 64-bit build. Other natural limit is 3 digit on 64-bit build
(enough to represent 64-bit C long on Linux or pointer on all platforms).
Larger integers perhaps are encountered mainly in tests.
Pre-allocating a block has a disadvantage. It is hard to free allocated block.
The program can create a lot of integers, then drop most of them, and request
the memory for other needs, but blocks once allocated for integers would not
freed. This is not trivial design decision and should be discussed on
Python-Dev and accepted by BDFL.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24138>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
