memoize wp_normalize_path #10770
memoize wp_normalize_path #10770
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
…josephscott/wordpress-develop into 64538/memoize-wp-normalize-path
There was a problem hiding this comment.
Pull request overview
This pull request adds memoization to the wp_normalize_path() function to improve performance by caching normalized path results. The implementation uses a two-tier cache system (hot and warm) to balance memory usage and cache hit rates.
Changes:
- Added memoization logic with a two-tier cache (hot/warm) limited to approximately 200 entries maximum
- Added test coverage for edge cases (empty strings, integers, stringable objects)
- Added tests to verify cache consistency across multiple calls
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| src/wp-includes/functions.php | Implements two-tier memoization cache for wp_normalize_path function with automatic rotation when cache exceeds 100 entries |
| tests/phpunit/tests/functions.php | Adds edge case tests for empty strings and integers, plus tests for stringable object handling and cache consistency |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This also makes sure that the hot segment is reset once it hits the max instead of waiting for it to go over.
|
I worked with Opus to address the issues brought up by Copilot. |
dmsnell
left a comment
dmsnell
left a comment
There was a problem hiding this comment.
thanks for your continued work on this @josephscott — it seems more-than-justified to take this approach, so I have left some comments relating to the actual implementation.
is the idea behind the hot/warm cache here mostly to get frequently-used paths cached while leaving some room for most-recently-used items to also be in the cache? a balance between long-term frequency and bursts of the same path? I would love to see a brief explanation of why this was chosen.
| * @since 3.9.0 | ||
| * @since 4.4.0 Ensures upper-case drive letters on Windows systems. | ||
| * @since 4.5.0 Allows for Windows network shares. | ||
| * @since 4.9.7 Allows for PHP file wrappers. |
There was a problem hiding this comment.
It’s worth adding a note that in 7.0 we are caching the paths, which in rare cases might return stale data, if a plugin has register a stream wrapper.
| $wrapper = ''; | ||
| $path = (string) $path; | ||
|
|
||
| static $hot = array(); |
There was a problem hiding this comment.
these could use explanation. happy to add or propose some if you prefer and are willing to wait a few days.
| public function __toString() { | ||
| return '/var/www/html\\test'; | ||
| } | ||
| }; |
There was a problem hiding this comment.
a more representative test might be an SplFileInfo instance, since that is actually used in Core. as discovered in #10781 we can fix that currently-improper call in another patch.
| $expected = array(); | ||
|
|
||
| // Generate 150 unique paths to exceed the 100-entry hot cache limit. | ||
| for ( $i = 0; $i < 150; $i++ ) { |
There was a problem hiding this comment.
while I wouldn’t normally want to suggest poking internally into a function like this, I think this is an appropriate test due to the fragile nature of the cache.
to that end, hard-coding 150 here and leaving a comment decouples the test from the code. what do you think about reading the max and basing the test off of it? I would hate for someone to come in and retune the max in a way that makes the tests pass when they should fail.
$function_reflector = new ReflectionFunction( '\wp_normalize_path' );
$max_cache_size = $function_reflector->getStaticVariables()['max'] ?? null;
$this->assertIsInt( $max_cache_size, 'Should have read max cache size from static variable "$max" inside "wp_normalize_path()" but found none: Check test setup.' );
for ( $i = 0; $i < 2 * $max_cache_size; $i++ ) {
…
}There was a problem hiding this comment.
ha! I see that you used this in the next test case but not here. LLMs being a little flight-of-mind on this?
| wp_normalize_path( $paths[ $i ] ), | ||
| "Second pass: Recent path {$i} should return correct result from hot cache." | ||
| ); | ||
| } |
There was a problem hiding this comment.
same note about basing our test on the actual configured max cache sizes in these two loop vs. hard-coding one.
2 participants
https://core.trac.wordpress.org/ticket/64538
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.