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 carljm, corona10, dino.viehland, eelizondo, gregory.p.smith, nascheme, pablogsal, pitrou, shihai1991, steve.dower, tim.peters, vstinner
Date 2020-04-16.04:14:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1587010479.1.0.413781911579.issue40255@roundup.psfhosted.org>
In-reply-to
Content
I was able to get an equal (maybe slightly better) performance by following the advice from Steve and Neil and skipping reference counting of instances that we know are immortal.

It seems that by getting performance parity, we should be able to ease most of the concerns raised so far.

I've updated the PR to now immortalize:
* All static types (i.e: PyType_Type, etc.)
* All small ints (-5 to 256)
* The following Singletons: PyTrue, PyFalse, PyNone
* And the heap after the runtime is initialized (in pymain_main)

A quick caveat, immortalizing the runtime heap caused ~6 or so tests to fail since they depend on shutdown behavior which this now changes. In the PR I commented out the call to `_PyGC_ImmortalizeHeap` in `pymain_main` to pass the CI. Ignoring these failing tests for now, these are the benchmarks numbers that I got from pyperformance:


Baseline (master branch):
unpack_sequence: Mean +- std dev: 76.0 ns +- 4.9 ns
richards: Mean +- std dev: 116 ms +- 8 ms
fannkuch: Mean +- std dev: 764 ms +- 24 ms
pidigits: Mean +- std dev: 261 ms +- 7 ms

Immortalizing known immortals objects (Latest PR)
unpack_sequence: Mean +- std dev: 74.7 ns +- 5.1 ns
richards: Mean +- std dev: 112 ms +- 5 ms
fannkuch: Mean +- std dev: 774 ms +- 24 ms
pidigits: Mean +- std dev: 262 ms +- 11 ms

Only adding immortal branch (The commit that Pablo benchmarked)
unpack_sequence: Mean +- std dev: 93.1 ns +- 5.7 ns
richards: Mean +- std dev: 124 ms +- 4 ms
fannkuch: Mean +- std dev: 861 ms +- 26 ms
pidigits: Mean +- std dev: 269 ms +- 7 ms


The performance of Immortal Objects by default seems to now be within error of the master branch.
History
Date User Action Args
2020-04-16 04:14:39eelizondosetrecipients: + eelizondo, tim.peters, nascheme, gregory.p.smith, pitrou, vstinner, carljm, dino.viehland, steve.dower, corona10, pablogsal, shihai1991
2020-04-16 04:14:39eelizondosetmessageid: <1587010479.1.0.413781911579.issue40255@roundup.psfhosted.org>
2020-04-16 04:14:39eelizondolinkissue40255 messages
2020-04-16 04:14:38eelizondocreate