[Tim]
>> In that case, it's because Python
>> _does_ mutate the objects' refcount members under the covers, and so
>> the OS ends up making fresh copies of the memory anyway.
[Greg Ewing ]
> Has anyone ever considered addressing that by moving the
> refcounts out of the objects and keeping them so
Tim Peters wrote:
In that case, it's because Python
_does_ mutate the objects' refcount members under the covers, and so
the OS ends up making fresh copies of the memory anyway.
Has anyone ever considered addressing that by moving the
refcounts out of the objects and keeping them somewhere
else
[Neil Schemenauer ]
> Python objects that participate in cyclic GC (things like lists, dicts,
> sets but not strings, ints and floats) have extra memory overhead. I
> think it is possible to mostly eliminate this overhead. Also, while
> the GC is running, this GC state is mutated, which destroys
Big +1. I love the idea.
str (especially, docstring), dict, and tuples are major memory eater in Python.
This may reduce tuple memory usage massively.
INADA Naoki
On Fri, Sep 8, 2017 at 2:30 AM, Neil Schemenauer wrote:
> Python objects that participate in cyclic GC (things like lists, dicts
On Thu, 7 Sep 2017 11:30:12 -0600
Neil Schemenauer wrote:
>
> * The GC process would work nearly the same as it does now. Rather than
> only traversing the linked list, we would also have to crawl over the
> GC object arenas, check blocks of memory that have the tracked bit
> set.
Small n
Python objects that participate in cyclic GC (things like lists, dicts,
sets but not strings, ints and floats) have extra memory overhead. I
think it is possible to mostly eliminate this overhead. Also, while
the GC is running, this GC state is mutated, which destroys
copy-on-write optimizations.
