[wp-trac] [WordPress Trac] #62692: Performance regression for get_option in 6.4
WordPress Trac
noreply at wordpress.org
Mon Dec 23 03:01:40 UTC 2024
#62692: Performance regression for get_option in 6.4
--------------------------------------+------------------------------
Reporter: rmccue | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Cache API | Version: 6.4
Severity: major | Resolution:
Keywords: has-patch has-unit-tests | Focuses: performance
--------------------------------------+------------------------------
Comment (by peterwilsoncc):
I've done some testing with an object cache in a pull request. The tests
are hacked up messes, but the [https://github.com/WordPress/wordpress-
develop/pull/8035/files#diff-
2f4fd4e950f239051cbb449ee9cc745f348e2e08e1534aec134adaddf7533a79R507
additional test is the important bit], determining how often the external
cache is hit when calling `get_option()` 10 times.
This is the number of calls to the external cache I am seeing in each case
(testing for `get`)
||= Option =||= Trunk =||= [https://github.com/WordPress/wordpress-
develop/pull/8030 PR#8030 (redo)] =||= Original reverted =||
|| Exists, autoloaded || 1 || 1 || 2 ||
|| Exists, not autoloaded || 3 || 12 || 3 ||
|| Non-existent || 12 || 3 || 3 ||
The redo removes the excess calls for non-existent options, but appears to
move the problem to options that are not autoloaded.
Given this, I think the best approach initially is to
* revert the original
* add tests for external cache hits (they need work so as not to break
[https://make.wordpress.org/hosting/test-results/ host tests] using a
different persistent cache implementation)
* continue work throughout the release to see if we can get the cache hits
down.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/62692#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list