Only invoke query_alter on tagged queries
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | database system |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
| Issue tags: | Performance |
Earlier tonight, sun and I were doing some hook profiling and discovered that most of the hook calls on a basic page come from either hook_url_outbound_alter() or hook_query*_alter(). In particular, on a fresh D7 just viewing a single node page, there's 23 calls to hook_query_alter(), more than any other hook, plus 17 more for tag-specific alters.
Even with the recently optimized drupal_alter() and module_implements(), that's still a lot of function calls that are unneeded most of the time.
I therefore propose that we alter (no pun intended) SelectQuery so that it only calls hook_query_alter() if there is at least one tag. An untagged query then does not go through the alter system at all, saving us some function calls. Then we remove stupid tags that don't really offer any value, like those that just name the function that the query is in. (Really, what?) That saves us even more.
This is especially relevant given that pager and tablesort queries are now all built, so they would ALL go through the alter system even if there's no reason for them to.
webchick said it made sense to her, but wanted to throw it up for discussion since it's technically then an API change. Anyone see a downside to this idea before I write a patch for it?

#1
Oops, forgot to tag it. :-)
#2
Makes sense to me. If there's any query which requires a tag later on due to that change, that's an individual bug in the query IMO.
#3
And patch, since no one is objecting...
#4
the point of those "stupid tags" is to make the query identifiable and alterable so please tackle those later if at all.
#5
It seems like the right thing to do, and it is faster by definition so let's give it a shot. Committed!
#6
Automatically closed -- issue fixed for 2 weeks with no activity.