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.

classification
Title: [sqlite3] Redundant type checks in pysqlite_statement_bind_parameter()
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.10
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: berker.peksag, erlendaasland, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2021-02-19 10:45 by erlendaasland, last changed 2022-04-11 14:59 by admin.

Files
File name Uploaded Description Edit
patch.diff erlendaasland, 2021-03-11 23:11
Messages (7)
msg387302 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-02-19 10:45
The type checks at the start of pysqlite_statement_bind_parameter() are redundant:
We first check for exact types (*_CheckExact()), and then we check again for exact or subtyped versions (*_Check()).

(Adding to the redundantness: the result of this if..else "switch statement" is then reused as the expression in the subsequent switch statement.)

Suggesting to remove the redundant checks and merge the two switch statements.
msg387334 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-02-19 17:33
It is a kind of optimization. We first perform few fast checks for exact types, and then slower subclass checks.

I do not know whether this optimization is worth, but it was written so, and there is nothing wrong in it.
msg387346 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-02-19 19:59
> It is a kind of optimization.

PyLong_Check is very fast (only one comparison, AFAICS), so there is no gain in first doing PyLong_CheckExact and then PyLong_Check. Ditto for unicode.

PyFloat_Check is the most expensive check, but it comes before both PyUnicode_Check and PyObject_CheckBuffer (both a lot faster), so that's AFAICS the opposite of an optimisation. Correct me if I'm wrong.

If we want to optimise it we should do PyLong_Check, PyUnicode_Check, PyObject_CheckBuffer, and then PyFloat_Check, no?

> there is nothing wrong in it.

True. I'll argue that my suggestion will improve readability and maintainability, which should be worth considering.
msg387448 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-02-21 10:03
PyLong_Check is two memory reads, bits operation, and comparison with 0. And one non-inlined function call when limited API is used. PyLong_CheckExact is only one memory read and comparison.

I am not sure that the difference is significant enough to justify the optimization. I would require evidences that this optimization is significant if it would be proposed now. But the code is already written in such form, and I am not sure that it is worth to spend our time to change it.
msg387464 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-02-21 15:58
> I am not sure that the difference is significant enough to justify the optimization.

I would guess it's negligible. I did some quick timeit tests, but the results were pretty much equal, so I guess I'd have to use a more precise benchmark method.

> But the code is already written in such form, and I am not sure that it is worth to spend our time to change it.

Not even a 30% reduction in code size (for this function)?
msg388529 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-03-11 23:11
$ python -m pyperf compare_to -G  main.json patched.json
Faster (1):
- bind: 63.6 us +- 1.2 us -> 61.8 us +- 0.9 us: 1.03x faster

$ git diff --shortstat master
 1 file changed, 41 insertions(+), 74 deletions(-)
msg388628 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-03-13 16:21
I would not add such "optimization", but it is up to Berker to keep or remove it. Please create a PR for review.
History
Date User Action Args
2022-04-11 14:59:41adminsetgithub: 87433
2021-03-13 16:21:43serhiy.storchakasetmessages: + msg388628
2021-03-11 23:11:11erlendaaslandsetfiles: + patch.diff
keywords: + patch
messages: + msg388529
2021-02-21 15:58:19erlendaaslandsetmessages: + msg387464
2021-02-21 10:03:35serhiy.storchakasetmessages: + msg387448
2021-02-19 19:59:37erlendaaslandsetmessages: + msg387346
2021-02-19 17:33:46serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg387334
2021-02-19 10:45:36erlendaaslandcreate