On 8/15/06, "Martin v. Löwis" <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
