Feature #21025
closed
Performance improvement for queries that expect just a single result row
Added by Jo Hasenau about 15 years ago.
Updated over 13 years ago.
Category:
Database API (Doctrine DBAL)
Description
I would like to introduce a new function exec_SELECTgetSingleRow() to prevent exec_SELECTgetRows() being used for queries that definitely expect only one row to be returned.
Just like exec_SELECTgetRows() it will contain all necessary function calls to execute the query, get the result row, free the result and return the data.
To avoid any additional function calls IMHO it should not be a variant of exec_SELECTgetRows() but another function.
Additionally it should be used in all places within the core, that are using exec_SELECTgetRows() but expecting single result rows only, to speed up the overall performance of the system. (An indicator could be LIMIT the rest can be recognized by checking the context)
Remaining question: If I create a patch should this contain all these changes at once or should this be done in different patches with their own bugtracker entry?
(issue imported from #M11916)
Files
Hy Jo,
depends on your patch - up to a few lines one entry is enough IMHO
Best Regards
David
Patch against TRUNK revision 5928 attached.
I replaced exec_SELECTgetRows with the newly created exec_SELECTgetSingleRow each time the following criteria has been met:
1) list(blah) has been used with getRows
2) LIMIT has ben set to 1
3) $result0 has been used only
4) other context that used only single results
There have been 31 places all over the core and the sysexts where singleRow would be the better choice.
In most of the cases list(blah) has been used before, which took 3 additional useless functions calls: a useless while loop, followed by a useless array_pop() and the useless list() after getRows returned $result0
So I guess the performance increase should be measurable.
Maybe someone with some more experience in performance testing can check the results.
I didn't touch the classes in the tests folder though.
@Olly: Since this was the first patch I sent to the bugtracker, I just want to know if it has been created according to the guidelines. If it's OK I would like to help out with other patches as well.
REMINDER and a question: What do I have to do to get this one in?
I did the research, created the function, found the places, where the function would be the better choice AND made a patch. - What else is necessary so that this wasn't just a waste of time?
Attached a new patch with CGL issues fixed
Committed (v7) to trunk, rev. 9454.
- Target version deleted (
4.5.0)
Also available in: Atom
PDF