[wp-trac] [WordPress Trac] #60787: get_registered_meta_keys() should allow for late registration to improve performance

[WordPress Trac]

#60787: get_registered_meta_keys() should allow for late registration to improve
performance
--------------------------------+------------------------------
 Reporter:  sc0ttkclark         |       Owner:  (none)
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  Options, Meta APIs  |     Version:
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:  performance
--------------------------------+------------------------------

Comment (by gaambo):

 With more and more things in WordPress moving to `register_*` APIs (which
 are great 🙏) instead of just "structurless" filters/actions, there's more
 "initializing" work that needs to be done on each request.
 In the past it has just been `register_post_type` and `register_taxonomy`
 (and maybe registering scripts/styles if you want to count them), but now
 we have many other functions: `register_block_type`,
 `register_block_pattern`, `register_block_pattern_category`,
 `register_block_style`, `register_meta` (+ variants like
 `register_post_meta`), `register_setting`, `register_rest_route`,
 `register_rest_field`.

 I think in general it would make sense to think for each one of those, if
 they need to run in any context or not.

 For example, post type and taxonomy registering need to run on every
 request. Block types possible as well. Registering rest routes/fields are
 already limited to `rest_api_init`. I think the performance team is
 looking into loading patterns only in the editor or at least caching them
 (because of the expensive file look-ups). Registering block variations was
 also deemed to be expensive therefore being moved into a callback which is
 only called in the editor.
 Registering settings may be required on each call (so you get default
 values are handled).

 Now I don't have any numbers myself, and I see that it would really make
 sense to get and compare them, before doing any premature optimizations.
 And maybe registering all of those things is really cheap, because these
 are just arrays in the memory.
 But I think many plugins need to do some database calls before/while
 registering those things - for example only registering a post type, if a
 feature is enabled or only registering meta fields to that post type if
 the feature is enabled. I've seen large plugins registering about 50
 different styles/scripts each with file system calls (for filemtime) and
 checking if a specific feature is enabled and the script is needed. That's
 not even touching custom field plugins, which store the whole
 configuration in the db.

 So while the core register functions may be cheap, there may be a lot of
 work "behind" it. Lazy "initializing" these things may be good. But again,
 I can't argue with any numbers, that's just what seems logical to me -
 maybe it really is overkill.


 While I think discussing "why" and "if" makes more sense before jumping
 into implementation, I just want to note that in core most hooks prefixed
 with `pre_` are there to shortcircuit the rest of the function. So if this
 is developed further, I think the hook should be called something else
 (like `register_meta_keys`). But that's just a small nit.

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