On 8/15/06, "Martin v. Löwis" <martin at v.loewis.de> wrote: > Guido van Rossum schrieb: > > From the Python *user*'s perspective, yes, as much as possible. But > > I'm still playing with the thought of having two implementation types, > > since otherwise we'd have to devote 4 bytes (8 on a 64-bit platform) > > to the single *bit* telling the difference between the two internal > > representations. > > We had this discussion before; if you use ob_size==0 to indicate > that it's an int, this space isn't needed in a long int. On a 32-bit > platform, the size of an int would go up from 12 to 16; if we stop > using a special-cased allocator (which we should (*)), there isn't > any space increase on such a platform. On a 64-bit platform, the > size of an int would go up from 24 bytes to 32 bytes. > > Regards, > Martin > > (*) people have complained that the memory allocated for a large > number of ints isn't ever reused. They consumed it by passing > range() some large argument. Since range() won't return a real list any more, this no longer is the case. I worry that dropping the special allocator will be too slow. And the space increase on 64-bit platforms is too much IMO. But clearly these issues can only be addressed by careful benchmarking. Perhaps we should do some of that to settle the issue. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4