Py_SETREF vs. Py_XSETREF
Originally I proposed a pair of macros for safe reference replacing to reflects the duality of Py_DECREF/Py_XDECREF. [1], [2] The one should use Py_DECREF and the other should use Py_XDECREF. But then I got a number of voices for the single name [3], and no one voice (except mine) for the pair of names. Thus in final patches the single name Py_SETREF that uses Py_XDECREF is used. Due to adding some overhead in comparison with using Py_DECREF, this macros is not used in critical performance code such as PyDict_SetItem(). Now Raymond says that we should have separate Py_SETREF/Py_XSETREF names to avoid any overhead. [4] And so I'm raising this issue on Python-Dev. Should we rename Py_SETREF to Py_XSETREF and introduce new Py_SETREF that uses Py_DECREF? [1] http://comments.gmane.org/gmane.comp.python.devel/145346 [2] http://comments.gmane.org/gmane.comp.python.devel/145974 [3] http://bugs.python.org/issue26200#msg259784 [4] http://bugs.python.org/issue26200
On 2016-04-03 08:32, Serhiy Storchaka wrote:
Originally I proposed a pair of macros for safe reference replacing to reflects the duality of Py_DECREF/Py_XDECREF. [1], [2] The one should use Py_DECREF and the other should use Py_XDECREF.
But then I got a number of voices for the single name [3], and no one voice (except mine) for the pair of names. Thus in final patches the single name Py_SETREF that uses Py_XDECREF is used. Due to adding some overhead in comparison with using Py_DECREF, this macros is not used in critical performance code such as PyDict_SetItem().
Now Raymond says that we should have separate Py_SETREF/Py_XSETREF names to avoid any overhead. [4] And so I'm raising this issue on Python-Dev.
Should we rename Py_SETREF to Py_XSETREF and introduce new Py_SETREF that uses Py_DECREF?
[1] http://comments.gmane.org/gmane.comp.python.devel/145346 [2] http://comments.gmane.org/gmane.comp.python.devel/145974 [3] http://bugs.python.org/issue26200#msg259784 [4] http://bugs.python.org/issue26200
Checking for NULL is convenient (and safer), but, on the other hand, it _would_ be consistent with the others.
Hi,
On 3 April 2016 at 15:29, MRAB
Should we rename Py_SETREF to Py_XSETREF and introduce new Py_SETREF that uses Py_DECREF?
Checking for NULL is convenient (and safer), but, on the other hand, it _would_ be consistent with the others.
My 2 cents would be to call the new macro Py_XSETREF for consistency, at least, whether you decide to go with two macros or not. Otherwise it's kind of obvious that if you add Py_SETREF that checks for nulls, in 2 or 3 releases people will really want a "fast" variant anyway, and there will be no consistent name for that. A bientôt, Armin.
On 3 April 2016 at 17:32, Serhiy Storchaka
Originally I proposed a pair of macros for safe reference replacing to reflects the duality of Py_DECREF/Py_XDECREF. [1], [2] The one should use Py_DECREF and the other should use Py_XDECREF.
But then I got a number of voices for the single name [3], and no one voice (except mine) for the pair of names. Thus in final patches the single name Py_SETREF that uses Py_XDECREF is used. Due to adding some overhead in comparison with using Py_DECREF, this macros is not used in critical performance code such as PyDict_SetItem().
I was one of those arguing for the single macro, and I think Alexander raises a good point in http://bugs.python.org/issue26200#msg262204 that I don't recall seeing in the original discussion: the "X" in the macro serves as a good shorthand for indicating that the code in question isn't closely tracking whether or not manipulated reference might be NULL, and hence may be a good candidate for additional micro-optimisations that keep better track of whether or not the pointer is NULL.
Should we rename Py_SETREF to Py_XSETREF and introduce new Py_SETREF that uses Py_DECREF?
With the single-macro design put into effect and concrete problems arising from that, I'm now more persuaded by the consistency argument than I was originally, so +1 from me for reverting to your original dual-macro proposal. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
If some dev don't want to use the single macro for good or bad reasons, it's maybe better to have two macros to generalize their usage. The macro makes to C code shorter and easier to review. Victor
Agreed, let's go with two macros. The time discussing this further
could be spent more productively.
On Mon, Apr 4, 2016 at 2:35 AM, Victor Stinner
If some dev don't want to use the single macro for good or bad reasons, it's maybe better to have two macros to generalize their usage. The macro makes to C code shorter and easier to review.
Victor
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
participants (6)
-
Armin Rigo -
Guido van Rossum -
MRAB -
Nick Coghlan -
Serhiy Storchaka -
Victor Stinner