[wp-trac] [WordPress Trac] #37114: Allow short-circuiting `get_post_class` for performance

[WordPress Trac]

#37114: Allow short-circuiting `get_post_class` for performance
-------------------------------------------------+-------------------------
 Reporter:  bordoni                              |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Posts, Post Types                    |     Version:  4.2
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-feedback needs-        |     Focuses:  template,
  testing                                        |  performance
-------------------------------------------------+-------------------------
Changes (by desrosj):

 * version:  4.6 => 4.2


Comment:

 [attachment:"37114.2.diff"] refreshes the filter and makes the passed
 arguments more consistent with the `post_class` filter at the end of
 `get_post_class()`.

 While I think this is a worthwhile filter to add because it allows
 unnecessary classes to be removed from the markup, neither of the
 solutions discussed so far here (short-circuiting the function vs.
 allowing the taxonomies to be removed with a filter) solve the underlying
 performance issue.

 In my test setup, I have 300 posts displaying on the home page with 20
 custom taxonomies registered (but I was able to experience the performance
 hit with as few as 30 posts displaying at once). Each post has random
 terms from random taxonomies assigned. The performance issue is being
 caused by the post term cache being primed in the main query on the page.
 This function consolidates individual queries for each public taxonomy
 attached to each post into one query for all posts being displayed on the
 page, reducing the number of queries from several thousand on my test
 setup to one.

 This large query can be prevented with the following code snippet:


 {{{
 function prevent_term_cache_prime( $query ) {
     if ( ! $query->is_main_query() ) {
         return;
     }

     $query->set( 'update_post_term_cache', false );
 }
 }}}

 However, the tradeoff with the snippet above is the number of queries
 increases exponentially. In my testing, the current behavior is actually
 much faster than using the code snippet above, but I do not have any
 caching enabled. With something like Memcached enabled, it may help
 prevent running all of those queries at once.

 Wondering if @boonebgorges would have any ideas for fixing this.

 Also, for reference, this was introduced in r31271.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/37114#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform