Set_blog_id performance

[wladwm]

On multisite many plugins switches blog (wbdb->set_blog_id) many times (few thousands).
There is a performance impact in wpdb->tables method.
Simple caching reduces overall execution time.

https://core.trac.wordpress.org/ticket/54479#ticket

Add tables names caching for multisite in wpdb->set_blog_id to improved performance with blogs switching.

Trac ticket: https://core.trac.wordpress.org/ticket/54479

[johnbillion]

Thanks for the PR @wladwm! And welcome.

Could you share some before and after performance numbers please? Would be good to see what impact this has.

Cheers

[wladwm]

Hi johnbillion.

On some pages delay for example was reduced from 5.92sec to 5.17sec.
But with some plugin I even cant open some pages w/o patch - cloudfare timeout occurs.
I did some debugging yesterday when discovered this issue with massive blog switching:

[flixos90]

Thank you for raising this @wladwm.

This change seems like a reasonable small performance win. Milestoning this for 6.9, since it already has a PR.

[SirLouen]

I can't see any performance testing and no ​performance use case apart from that image that was retired 4 years ago.

I think this is required, as @johnbillion pointed out back in the day, to see how real impact with numbers.

[khoipro]

I think the Performance team should take care of this change: review and see benchmark. It should be a little bit better, but we can consider to complete fix or retire it.

[westonruter]

Added a review to the PR. I agree that we should get some benchmarks on what impact this change has.

[welcher]

This was reviewed in the bug scrub today. We're getting very close tot he beta 1 cut off, do we think the PR can be refreshed in time?

[westonruter]

Punting to future release since beta1 is next week and the patch still needs refreshing.

WCEP-54479-EVIDENCE-V0.1.0

## Controlled correctness evidence for PR #10281 / Core Trac #54479

I tested the exact current PR #10281 implementation in a controlled baseline/candidate comparison.

### Implementation identity

• PR head: 8841858cf7d741b4545407d8d7bd47a210fd0f54
• Stable patch ID: 561ae115ab44121ff3ed2282af3aede68cff61ef
• Tested base commit: c90e0c03ca1c23c92937d573b17d975b7d922181
• Runtime: PHP 8.4.24, PHPUnit 9.6.36, MySQL 9.7.2

For every defect probe, the test was run against baseline first. Candidate execution reused the same runtime/database and used a read-only overlay of the candidate class-wpdb.php.

### Reproduced candidate assertion failures

1. set_prefix() invalidation

After base_prefix changed, revisiting the same blogid/siteid restored:

wptests_2_posts

instead of the freshly derived:

wcep54479_2_posts

2. $wpdb->tables mutation

After adding a table identity to $wpdb->tables, fresh tables( 'blog' ) contained the new table, but the corresponding wpdb property was not materialized on the same-key cache hit.

3. $wpdb->old_tables mutation

The equivalent mutation to $wpdb->old_tables produced the same class of failure: fresh tables( 'old' ) contained the new table, but the corresponding property was not materialized on the cache hit.

4. Global/blog classification mutation

After reclassifying posts as global, fresh tables( 'blog' ) derived:

wptests_posts

while the candidate cache restored:

wptests_2_posts

### Positive controls

Two controls passed against both baseline and candidate:

• repeated set_blog_id( 2, 1 ) with no output-determining state mutation;
• alternating stable blog 2 / blog 3 identities and returning to each cached identity.

The positive controls indicate that the cache behaves equivalently when its output-determining state remains stable.

### Bounded conclusion

For this exact patch, blogid~siteid is sufficient for the stable-state cases tested, but it does not represent all mutable state that determines the cached tables( 'blog' ) / tables( 'old' ) mappings.

This is broader than only a missing set_prefix() invalidation path: the controlled failures independently cover base_prefix, $tables, $old_tables, and global-vs-blog classification state.

I am not claiming that caching itself is invalid, that all possible wpdb mutations have been tested, or that a specific repair is established. I also have not benchmarked this implementation. The evidence suggests the correctness issue should be resolved before performance results determine readiness of this exact implementation.

### Evidence package

A validated evidence package was produced locally:

WORDPRESS_CORE_54479_PR_10281_CORRECTNESS_EVIDENCE_V0.1.0.zip

SHA-256:

3530B7CA3A0757408E0D62E60F78BB68EEF0D1CDAC5970C7417EFB233FA2655B

It contains the six exact PHPUnit test artifacts, their SHA-256 identities, concise execution receipts, reproduction instructions, the machine-readable evidence manifest/schema, and package validation receipt.

The ZIP is not currently attached to Trac. Direct terminal access to Core Trac XML-RPC from this external network returned WordPress.org's JavaScript browser challenge before the XML-RPC endpoint could execute. The evidence summary and exact identities are therefore included directly in this comment.

AI-use disclosure: AI assistance was used to help design and organize the controlled experiment and evidence package. The factual results reported here come from direct execution receipts and exact test/source/patch identities.