#64538: memoize wp_normalize_path
--------------------------------------+--------------------------
Reporter: josephscott | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: 7.0
Component: General | Version:
Severity: normal | Resolution:
Keywords: has-patch has-unit-tests | Focuses: performance
--------------------------------------+--------------------------
Comment (by josephscott):
I was looking at https://github.com/WordPress/wordpress-develop/pull/10781
to see what it would do performance wise. After a bit I realized that I
was juggling a fair number of variations of this work on
wp_normalize_path() and was testing it in a environment with a huge number
of moving parts. It felt like a good time to pull back and really re-
evaluate what is going on, and to do it in a stand alone way.
Working with Claude I put together a stand alone benchmark script that
tries the various approaches and compares them -
https://github.com/josephscott/wp-normalize-path - and this turned out to
be really helpful.
In these isolated tests the segmented cache did not perform as well. That
ultimately led me to have Claude automatically try out variations it could
think of and use the benchmark script to see how well they did. That is
why the script has other variations in it that are not included in the
output.
The original simple cache ended up being a better option than the
segmented, original, and the variation @dmsnell has in
https://github.com/WordPress/wordpress-develop/pull/10781. But Claude
made a few tweaks to the simple approach that gave up a bit of the
performance win for less memory usage. It labeled that variation "best".
A few other changes I made - the benchmark doesn't include Windows and UNC
paths. I expect the vast majority of WP installs are only dealing with
Unix like environments. So I simplified the paths to be tested to focus
on that.
Another data point that I found interesting. My practically fresh WP
install from wordpress-develop does about 800 calls to
`wp_normalize_path()`. Meaning out of the box this would add less than
60KB to PHP memory and reduce the time spent by ~0.2 seconds ( in my local
Apple Silicon M3 test results ).
I'm hoping that by making this public and easy for anyone to use that we
can zero in on a final solution. And of course if you find any bugs, or
have other variations that should be tested, this is easy to update.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/64538#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform