I think we might be able to defer descriptions to be a callback and only execute them when actually called. . .like in introspection queries, for example. 🤔

Additionally, the whole schema seems to be created and queried during each request, generating a massive object that is impossible to cache.

@creative-andrew I don't believe this is the case.

Let's take a look:

WordPress, no plugins

If we setup a fresh WordPress install (I'm using localwp to do it) and visit the /graphql endpoint WordPress will do it's thing and ultimately return a 404 (because WPGraphQL is not active)

But we can use this as our baseline of WordPress execution.

We can see that the "apply_filters" gets called 8,246 times

And then we can dig in and see that "translate" calls it 1,954 times.

If we visit the /wp-json/wp/v2/posts endpoint, we will see similar information.

"apply_filters" is called 8,887 times for this REST endpoint, and "translate" is called 4,110 times.

If we visit the /wp-json/wp/v2 endpoint, we see the following:

"apply_filters" is called 17,108 times for this REST endpoint, and "translate" is called 8,218 times.

WPGraphQL Active

If we activate WPGraphQL (v1.13.8) and visit the /graphl endpoint, this time we don't get the 404, instead we get the WPGraphQL error message saying we need to pass a query.

If we look at the profiling for this request, we'll see the following:

apply_filters called 13,401 times, 9,654 of them from translate.

If we go back to WPGraphQL v1.6.5 (shortly after the 1.6 release that targeted the "lazy loading" problem) we would see the following output:

apply_filters called 12,817 times, 9,306 of them from translate.

So yes, a there's an increase from some of the other endpoints, but definitely not the whole schema worth.

If we go back to WPGraphQL v1.5.9, before the v1.6.0 release, we will see a significant change in the profiling, just by visiting the graphql endpoint and not even executing a query:

Here we see apply_filters called 21,112 times, (increase from 12,817 in v1.6.5)
strtolower called 12,811 times (increase from 1,192 in v1.6.5)
WPGraphQL\Registry\TypeRegistry->format_key called 10,011 times, (increase from 898 in v1.6.5)
preg_match called 8,389 times (increase from 1,834 in v1.6.5)

I definitely think we have something to address here, but I don't think we have a regression to the 1.6 release. I don't see evidence suggesting that "the whole schema seems to be created and queried during each request".

This would be true for Introspection Queries, but I don't believe it's the case for every query.

Now, when queries are executed, the Types required to fulfill them will be loaded, so that would have an increase as well, but definitely not to the scope of loading the whole schema for each request.

So, the more complex queries get, the more types will be loaded, so I would expect an increase in Types being loaded for more complex queries.

I think we definitely should look into how we can register Types/Fields so that the descriptions are only executed/translated when needed (i.e. in Introspection Queries), but again, I don't believe there's evidence of a regression to 1.6 where the entire Schema is being loaded.

(related: caching get_schema() thread on slack )

Related https://wp-graphql.slack.com/archives/C3NM1M291/p1684225596339229

Just for clarifying when I mentioned that the schema was called or registered on every request, I meant the schema inflation process.

From core: https://make.wordpress.org/core/2023/07/24/i18n-performance-analysis/

Seems like adopting lazy-loading is the way to go, while still benefiting from any upstream improvements to the parser.