Pre-cache post_meta for nav_menu_items rather than querying one at a time

[mitchoyoshitaka]

We know that wp_get_nav_menu_items is going to have to get_post_meta on each individual nav menu item, and unless it's already cached, each of these get_post_meta will spawn their own database query to update_meta_cache.

Instead, we could update_meta_cache once on all of the objects which we know we're going to hit at the beginning of wp_get_nav_menu_items.

Here's the effect of this patch on DB queries on a site I'm working on, with two decently sized nav menus: (averaged over 10 hits)

3.3-trunk: 69 ms, 198 queries

with patch: 55 ms, 142 queries

Are these front-end queries? Cause this doesn't look right at all. The 198/142 look more like the admin.

18369.2.diff​ significantly reduces the number of queries that are run on the admin -- rough estimate, by about two-thirds. More optimizations are likely possible.

Replying to nacin:

Are these front-end queries? Cause this doesn't look right at all. The 198/142 look more like the admin.

The ridiculous number of queries was a combination of the admin bar loading, a couple complex nav menus (which I'm now caching), and a bug with W3 Total Cache which I'm reporting. It's a site still early in development but yes, client side. Now down to 32 queries.

18369.2.diff​ significantly reduces the number of queries that are run on the admin -- rough estimate, by about two-thirds. More optimizations are likely possible.

Why are you keeping update_post_term_cache false on the client side?

Replying to mitchoyoshitaka:

Now down to 32 queries.

Can you post them? Also the code you're using for wp_nav_menu (and any associated callbacks or walkers).

Why are you keeping update_post_term_cache false on the client side?

There's no way core does this all of these queries on its own. I suspect something else is causing quite a number of queries. We would have fetched postmeta initially if we had needed them.

Nevermind, this was a weird interaction between W3 Total Cache and some code we had running. The site no longer is configured as it was when this issue occurred, so I can't really reproduce it. Nacin, should we go ahead and close this? Or do the tickets here still merit committing?

In that case, you might be running into the fact that under a persistent cache, WP won't bother caching metadata or term data via WP_Query.