[wp-trac] [WordPress Trac] #40988: Use objects for `get_item_schema()` calls

WordPress Trac noreply at wordpress.org
Sat Jun 10 06:07:56 UTC 2017

#40988: Use objects for `get_item_schema()` calls
 Reporter:  schlessera             |      Owner:
     Type:  enhancement            |     Status:  new
 Priority:  normal                 |  Milestone:  Awaiting Review
Component:  REST API               |    Version:  4.7
 Severity:  normal                 |   Keywords:
  Focuses:  rest-api, performance  |
 The `get_item_schema()` method of a REST API controller always returns a
 dynamically generated array of schema information. This dynamic nature is
 needed, because some keys/values can change based on the current

 This incurs a large performance penalty because the arrays need to be set
 up again and again, and as a side-effect, the translations that are being
 used for the `'description'` field are being loaded every single time. On
 a fresh, empty install of WordPress 4.8, making a request to `GET /wp-
 json/wpv2/posts` can spend a third or more of its time translating
 strings. Most of these translations are done multiple times, every single
 time an item schema is being requested. See blackfire profiling run here:

 I suggest turning the arrays that `get_item_schema()` returns into a
 collection of smart objects that implement `ArrayAccess`. This offers the
 following benefits:

 * Objects use up the memory for their keys once.
 * Objects can be cloned (with the possibility to make changes after the
 clone), making sure that translations will at the most be loaded only once
 for every individual string.
 * Objects can be extended and/or decorated, making it easy and clean to
 provide different structures for different use case, to get around
 `if/else` edge case handling.
 * Objects can provide "lazily-loaded" keys (through magic methods or the
 proxy pattern), allowing the descriptions to only be processed when they
 are actually being requested. This would avoid the translation work
 completely for a use case like I tested above.

 I expect this to shave around 30% off of the execution time of the above
 test case. It also makes the code more scalable, as large response sets
 might even incur yet a bigger performance penalty than the one I have

Ticket URL: <https://core.trac.wordpress.org/ticket/40988>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

More information about the wp-trac mailing list