[wp-trac] [WordPress Trac] #35816: Add "after_get_posts" action to `WP_Query::get_posts()`

[WordPress Trac]

#35816: Add "after_get_posts" action to `WP_Query::get_posts()`
---------------------------+--------------------------
 Reporter:  stevegrunwell  |       Owner:
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  4.5
Component:  Query          |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:  performance
---------------------------+--------------------------

Comment (by boonebgorges):

 @lpawlik Thanks for sticking with me here :)

 > What kind of benefits we have by distinguishing WP_Query instances?

 Well, two kinds of benefits, I guess. First, a general separation of
 concerns. It feels aesthetically weird that doing something inside of one
 post loop would reach out and touch other query loops. Second, a concern
 about performance. If you have two loops, one with 5 posts and one with
 100, it feels odd that calling `get_term_meta()` in the first one would
 cause termmeta to be loaded for terms belonging to all 105 posts.

 But I've taken some time this morning to get some actual numbers behind
 these hunches. I set up an installation with 10,000 terms, all with some
 term meta. Then I assigned 10 of these terms to 1,000 different posts. I
 then ran some profiling where I fired up 100 different `WP_Query` objects
 (basically, paginating through all posts). I was able to reproduce your
 report of memory overhead from `$wp_filter`. I then started working with
 your patch and I found that very little overhead was associated with the
 call to `update_termmeta_cache()`, which means that my concern about
 keeping `WP_Query` instances separate probably is not warranted. It
 certainly simplifies the lazyloading logic if we can simply dump all of
 the posts in a single pot, and it doesn't seem to have serious performance
 implications in anything but the most extreme cases.

 [attachment:35816.2.diff] builds upon your POC. It shows how it might
 integrate into WP with file structure, naming, etc. It abstracts the
 `$meta_type` so that the same logic can be used for commentmeta too
 (though I haven't implemented that yet). And it eliminates the check that
 causes metadata to be loaded only for those terms belonging to posts
 attached to the `$term_id` (gosh, that's confusing). Instead: the first
 time that `get_term_meta()` is called, termmeta cache is primed for all
 pending posts.

 > One extra note: we could keep only post ID and post_type inside
 WP_Query_Lazy_Load instead of all WP_Post data which would reduce memory
 requirements.

 I implemented this too.

 What do you think of this direction?

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