Author josh.r
Recipients josh.r, pablogsal, tim.peters, vstinner, xtreak
Date 2019-02-12.19:11:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1549998700.18.0.0988658854342.issue35961@roundup.psfhosted.org>
In-reply-to
Content
Ah, I see Victor posted an alternative PR that avoids the reference counting overhead by explicitly removing the temporary tuples from GC tracking. I'm mildly worried by that approach, only because the only documented use case for PyObject_GC_UnTrack is in tp_dealloc (that said, the code explicitly allows it to be called twice due to the Py_TRASHCAN mechanism, so it's probably safe so long as the GC design never changes dramatically). If slice comparison really is performance sensitive enough to justify this, so be it, but I'd personally prefer to reduce the custom code involved in a rarely used code path (we're not even caching constant slices yet, so no comparisons are likely to occur for 99.99% of slices, right?).
History
Date User Action Args
2019-02-12 19:11:40josh.rsetrecipients: + josh.r, tim.peters, vstinner, pablogsal, xtreak
2019-02-12 19:11:40josh.rsetmessageid: <1549998700.18.0.0988658854342.issue35961@roundup.psfhosted.org>
2019-02-12 19:11:40josh.rlinkissue35961 messages
2019-02-12 19:11:40josh.rcreate