Eddie Elizondo <eduardo.elizondoru...@gmail.com> added the comment:

Mark:
> 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 speed.python.org 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 :)

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue40255>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to