Since 7.x we see a performance regression. This has also been reported to Support, but it fits better here in as Github issue. When looking into our performance regression, Yoast came up as a possible suspect. After our update to Yoast SEO Premium 7.x our performance monitoring graphs declined.
We did extensive debugging through Blackfire traces and git bisects and we found the following "issues" that could possibly improve the performance of Yoast.

In this timeline you can see WPSEO_Options::get_all() is called and each time takes a long time to do so. We see a lot of option retrieving, merging and intersecting of arrays is taking place.
I also noticed ::get_all method is only used by ::get, therefore I optimized the ::get_all like:
public static function get_all() {
static $options = null;
if ($options === null) {
$options = self::get_options( self::get_option_names() );
}
return $options;
}
This gives us the following change:


In our own application (running local) this shaves about 15% of the total request time and CPU time in total. This has effects on other hooks too, which is a nice bonus.
I cannot really see any complications by caching the ::get_all like that, but there might be some drawbacks that someone else can see (if there is no problem, I can ofcourse submit this as a PR).
As a follow up to this I also looked at how the JSON-LD code worked and noticed a pattern that is very harmful if the ::get_all can't be optimized like my code above.
foreach ( $social_profiles as $profile ) {
- if ( WPSEO_Options::get( $profile, '' ) !== '' ) {
- $this->profiles[] = WPSEO_Options::get( $profile );
+ if ( ( $social_profile_option = WPSEO_Options::get( $profile, '' ) ) !== '' ) {
+ $this->profiles[] = $social_profile_option;
}
}
There are a lot of instances where the option value is retrieved, asserted it is not an empty string and than the value is discarded and retrieved again. My diff does all the assertion and retrieving in one line.
@stayallive thanks a ton for this bug report and sorry for not picking this up earlier.
We've been testing this and ran into loads of problems. This might be related to our test suite and how we handle changing options there, but unfortunately we won't be able to fix this as such right now. We're working on another major performance improvement in our Indexables branch, we might revisit this change after that if it's still needed.
hey @stayallive I tested another approach to this today and found that to work. Could you by any chance run your test again with the jdv/options-get-all-improvement branch?
@jdevalk thank you for picking this up! As you might have noticed I did not have the time to check if this has a similar impact in our environment (not working with it daily anymore), however reading through the code it does seem like it would 馃挭.
So thank you @jdevalk and @andizer for taking the time to fix my suggested changes 馃憤