edd_get_option() is slow
#9743
Labels
type-bug
workflow-needs-replication
workflow-pending-triage
Items that need to be triaged and reviewed before they are worked on.
Comments
zackkatz
added
type-bug
workflow-needs-replication
workflow-pending-triage
|
Hey @zackkatz thank you for submitting this and the supporting research. I agree that this is an area we can look at improving, but we need to ensure that it will work with any kind of filter no matter where it's run. So it may work on a tightly controlled and configured site, but we need to account for the many different ways code interacts with EDD. I'm logging this for us to look into, and we'll keep you updated on our progress. |
|
Hi @robincornett, yep, I have zero expectations of a quick merge! I know this is going to require lots of testing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A close cousin to #9741 ! Same reasoning: a function that's called this many times should be performant. Re-running filters each time it's called is slow.
Calls
The function is called over 65 times on a single front-end page load on my site:
A potential fix: static caching
By applying a simple static cache, the function fully processes once per request.
Stats
These are numbers generated using the Code Profiler Pro plugin:
Potential downsides to this fix:
Since the filters are currently being run after each call, and the function is called in so many places, perhaps a plugin may want to modify the response from
edd_get_option()inside one of the callers and not another. Or hook in and then remove the filter.These concerns have more validity than the
edd_is_checkout()question, which is "is this a checkout page". Theedd_get_option()filter is related to options that may be manipulated differently based on the caller.I'll leave this up to you, but I'll put forward a PR. It's improved speed on my site.
The text was updated successfully, but these errors were encountered: