-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CRM-20455 - DB_common::modifyQuery() - Optimize #259
Conversation
Overview -------- The recently merged PR civicrm#180 added `modifyQuery()` to allow dynamic inspection/modification of most SQL queries (*post-boot*). This patch modifies and micro-optimizes the new (unreleased) interface. Ordinarily, one wouldn't care about this level of micro-optimization; however, it's entirely foreseeable that this code will run hundreds or even thousands of times while a user works with a single page. Before ------ For each typical SQL query, the call to `modifyQuery()` requires: * Constructing an instance of `GenericHookEvent`, which does some array shuffling and encourages reflective code. * Performing multiple lookups of the container/dispatcher system After ----- For each typical SQL query, the call to `modifyQuery()` requires: * Constructing an instance of `QueryEvent`, which is a lighter object * Fewer lookups (`isset(Civi::$static[...])`) Comments -------- I did some simple benchmarks -- running 10,000 simple SQL queries with various forms of `modifyQuery()`. The baseline (no events) had the fastest average (`9.444`s). Adding GHE bumped runtime up +9% (`10.298`s). With this patch, it only adds +3.5% (`9.787`s). The averages are based on 5 samples each. For full details, see https://gist.github.com/totten/da21a8386a7ddcc62def5d78e912bf8c
(Standard links)
|
thanks @totten 300ms over 10k queries seems OK to me & def better! |
Error was
which makes sense as the core PR hadn't been merged |
Jenkins re test this please |
Cool, the second test-run showed that 14882 fixed the |
test this please |
Just a note that I'm doing some performance tests before deploying some updates. My first tests on 5.13 were importing (via script) around 462 contacts with contributions per minute. On 5.17 both with and without using this query modifier I was getting around 484 contributions per minute. I don't consider the above to be reliable enough to say 5.17 is definitely faster than 5.13 but I think it is reliable enough to say the query modifier is not dragging us down |
Overview
The recently merged PR #180 added
modifyQuery()
to allow dynamic inspection/modification of most SQL queries (post-boot).This patch modifies and micro-optimizes the new (unreleased) interface.
Ordinarily, one wouldn't care about this level of micro-optimization; however, it's entirely foreseeable that this code will run hundreds or even thousands of times while a user works with a single page.
Depends: civicrm/civicrm-core#14882, civicrm/civicrm-core#14883
Before
For each typical SQL query, the call to
modifyQuery()
requires:GenericHookEvent
, which does some array shuffling and encourages reflective code.After
For each typical SQL query, the call to
modifyQuery()
requires:QueryEvent
, which is a lighter objectisset(Civi::$static[...])
)Comments
I did some simple benchmarks -- running 10,000 simple SQL queries with various forms of
modifyQuery()
. The baseline (no events) had the fastest average (9.444
s). Adding GHE bumped runtime up +9% (10.298
s). With this patch, it only adds +3.5% (9.787
s).The averages are based on 5 samples each. For full details, see https://gist.github.com/totten/da21a8386a7ddcc62def5d78e912bf8c