But Python’s present scheme for maintaining reference counts (the
“Global Interpeter Lock” or “GIL”) prevents Python code for taking full
advantage of multiple threads. Some are advocating switching to the
pure garbage-collection approach, but fortunately (I think) this is not
the plan that has been adopted by the Council.
Instead, they are going to use a technique known as “Biased Reference Counting”.
This seems to offer the best performance in tests so far.
Seems some people are still smarting over the flak they got from the
Python 2 → 3 transition. “This is not Python 4,” they are saying. But why not call it “Python 4”, as a warning over the likely compatibility issues? Even if it probably won’t be quite as painful ...
... the idea that GC uses more memory seems erroneous to me.
So even a very simple, seemingly well-behaved Python script, if
running for long enough, would consume more and more memory if it were
not for reference-counting.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
So even a very simple, seemingly well-behaved Python script, if running
for long enough, would consume more and more memory if it were not for
reference-counting.
That is completely false. It's usual to set a GC to [fix it so it’s not false] ...
not to
mention the latency when there isn’t quite enough memory for an allocation and you have to wait until the next GC run to proceed. Run the GC a
thousand times a second, and the latency is still 1 millisecond.
In other words, it’s not “completely” false if you have to do something to
make it false.
But that GC process creates its own overhead
not to mention the latency when there isn’t quite enough memory for an allocation and you have to wait until the next GC run to proceed.
With reference counting, most objects are immediately freed as soon as
they are discarded--no need to wait for the next GC run.
FYI you're violating someone's request by responding to them in a way
that results in it getting onto python-list,
In CPython, the only reason to "run garbage collection" is to detect
cycles
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 80:02:18 |
Calls: | 6,716 |
Files: | 12,247 |
Messages: | 5,358,007 |