This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eelizondo
Recipients Mark.Shannon, carljm, corona10, dino.viehland, eelizondo, gregory.p.smith, nascheme, pablogsal, pitrou, shihai1991, steve.dower, tim.peters, vstinner
Date 2020-04-16.15:10:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> You are asking the whole world to take a hit on both performance and memory use.

That's an explicit non-goal. That's why the code was guarded to add as an optional compilation mode

This should be added by default if and only if this is a neutral or an improvement on performance. Which by the way, the latest perf numbers suggest that we are now at perf parity / within error (pending official confirmation from running this on machines).

Also, can you expand on how is this a performance hit on memory?

> There is only one reference to copy-on-write in a comment. Yet this issue about making object headers immutable.

The PR summary expands on Copy on Writes. If you think this belongs in-code, let me know and I can update the PR.

> then make the obvious improvement of changing the branchy code

That is strictly slower. The current version makes Py_INCREF and Py_DECREF cheaper for known immortal instances (i.e the heap after runtime init). This skips increasing and decreasing the refcount as well as the refcount check for deallocation. Using the proposed branch-less version makes all Py_INCREFs and Py_DECREFs more expensive.

I ran a couple of benchmarks with the branch-less version to highlight this:

Branch-less version:
unpack_sequence: Mean +- std dev: 98.2 ns +- 4.9 ns
richards: Mean +- std dev: 130 ms +- 5 ms
fannkuch: Mean +- std dev: 894 ms +- 18 ms

Branch version:
unpack_sequence: Mean +- std dev: 82.7 ns +- 3.9 ns
richards: Mean +- std dev: 123 ms +- 4 ms
fannkuch: Mean +- std dev: 838 ms +- 25 ms

> Immortality has advantages because it allows saturating reference counting and thus smaller object headers, but it is not the same as making the object header immutable.

In its current form, this change is not trying to do a strict immutability of the header. We can't guarantee that third-party extensions won't mutate the instance. Instead, this change tries to maintain an instance's immutability as long as it can.

If the issue is with naming, I can easily rename this to something else :)
Date User Action Args
2020-04-16 15:10:46eelizondosetrecipients: + eelizondo, tim.peters, nascheme, gregory.p.smith, pitrou, vstinner, carljm, dino.viehland, Mark.Shannon, steve.dower, corona10, pablogsal, shihai1991
2020-04-16 15:10:46eelizondosetmessageid: <>
2020-04-16 15:10:46eelizondolinkissue40255 messages
2020-04-16 15:10:46eelizondocreate