[wp-trac] [WordPress Trac] #11092: get_body_class() needless messes with global variables

[WordPress Trac]

#11092: get_body_class() needless messes with global variables
--------------------------+-------------------------------------------------
 Reporter:  filosofo      |       Owner:  ryan                           
     Type:  defect (bug)  |      Status:  new                            
 Priority:  normal        |   Milestone:  2.9                            
Component:  Template      |     Version:  2.9                            
 Severity:  normal        |    Keywords:  get_body_class has-patch tested
--------------------------+-------------------------------------------------

Comment(by Denis-de-Bernardy):

 Replying to [comment:3 filosofo]:
 > Can you substantiate your suspicions?

 Sure...

 >  Here's the actual database query for a page using my patch:
 >
 > {{{
 > SELECT * FROM wp_posts  WHERE (post_type = 'page' AND post_status =
 'publish')    AND post_parent = 37   ORDER BY post_title ASC LIMIT 0,1
 > }}}
 >
 > and here it is without the patch (current behavior):
 >
 > {{{
 > SELECT ID FROM wp_posts WHERE post_parent = 37 AND post_type = 'page'
 LIMIT 1
 > }}}
 >
 > Both claim to take 0.00 seconds with the query cache off.

 these two queries potentially have very different behaviors in reality.

 had there been an index on (post_parent, post_type) the second one would
 be proceed as follows:

  1. open index on (post_parent, post_type) if it's not loaded in the
 memory already
  2. scan index for post_type = page with post_parent = 37 (fast)
  3. return the first ID found (fast)

 since we're missing that index, it'll actually load rows one by one and
 return the ID of the first row it finds that works (making it much slower
 than it should be):

  1. open the relevant index (likely post_parent in your example)
  2. scan index for rows that work (fast)
  3. '''until''' an ID is found, open the needed disc page if needed (slow)
 and load the ''field'' we're missing (post_type) for that row (fast)
  4. filter rows that don't work (fast)
  5. return the first ID that works (fast)

 by contrast, the query using the API does:

  1. open whichever index the query engine decides is correct (probably
 post_parent in your example) if not loaded already
  2. scan index for IDs that potentially work (fast)
  3. ''' for each''' ID, open the needed disc page if needed (slow) and
 load the ''fields'' we're missing (post_type, post_title) for that row
 (fast)
  4. filter rows that don't work (fast)
  5. filter if it's not the first row (order by post_title limit 1) (slow
 if the result set is large, and I'm probably wrong to make the assumption
 that MySQL does a top-1 search on the fly instead of a quicksort on the
 full set)
  6. load the ''entire'' row (slow)
  7. return the ''entire'' row (slow if post_content is large)

 I hope my suspicions make more sense...

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/11092#comment:4>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software