Feature #21025
closed
Performance improvement for queries that expect just a single result row
0%
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
Updated by David Bruchmann about 15 years ago
Hy Jo,
depends on your patch - up to a few lines one entry is enough IMHO
Best Regards
David
Updated by Jo Hasenau about 15 years ago
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.
Updated by Jo Hasenau about 15 years ago
@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.
Updated by Jo Hasenau over 14 years ago
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?
Updated by Jo Hasenau about 14 years ago
Attached a new patch with CGL issues fixed
Updated by Ernesto Baschny about 14 years ago
Committed (v7) to trunk, rev. 9454.
Updated by