Improve the performance of `WP_Image_Editor_Imagick::supports_mime_type()`

[joemcgill]

WP_Image_Editor_Imagick::supports_mime_type() is called whenever WordPress is choosing which image editor library to use via wp_image_editor_supports() > _wp_image_editor_choose().

To see if the current server's version of ImageMagick supports a specific mime type, that method calls Imagick::queryFormats(), which can take a long time to run.

In the editor, wp_plupload_default_settings() makes triggers this code path to see if modern formats like WebP and AVIF are supported, which leads to a slower editor load time.

Since these supports values rarely change except for when changing hosting environments, we can cache these supports values for faster lookups.

Trac ticket: https://core.trac.wordpress.org/ticket/61532

Great idea, love it! Curious how you came to the realization that the mime type check call was slow/expensive? Did you see it in a trace somewhere?

I think a more comprehensive solution would be to cache part of what _wp_image_editor_choose() does, for example:

Interesting idea to add caching up at this level, although this PR's changes could still be useful for supports_mime_type since that could be called from elsewhere including plugins.

My one concern would be ensuring the cache has some expiration so we can catch new capabilities when users upgrade their systems. This brings me back to wondering how significant this improvement is - does profiling indicate this function is problematic?

My one concern would be ensuring the cache has some expiration so we can catch new capabilities when users upgrade their systems. This brings me back to wondering how significant this improvement is - does profiling indicate this function is problematic?

This is a good point, would be good to clarify _how_ bad the performance of the uncached function makes it. And related to expiration, I wonder: @joemcgill Are you thinking this should be persistently cached, or would it already benefit to be cached non-persistently (e.g. because the function is called many times during a single page load)?

Why aren't the unit tests and other GitHub jobs working for this PR?

[mukesh27]

@joemcgill Could you please address the feedback on PR!

Why aren't the unit tests and other GitHub jobs working for this PR?

I've seen this happen before if the PR is opened with a base branch that does not contain GitHub Action workflows (such as the old master branch).

It does not show that the base branch for the PR was changed after opening, but I've gone and merged the current state of trunk into this branch and it seems like everything is now running!

[chaion07]

Thanks @joemcgill for reporting this. We reviewed this Ticket during a recent bug-scrub session. Here's the summary of the discussion:

1. The changes requested have not yet addressed in the PR. So we would appreciate if that is addressed sometime soon
2. Seconding with Mukesh's comment
3. As we are in the Beta stage of the 6.7 release, we would wait for a couple of days before updating the milestone later on

Thank you.

Props to @pratiklondhe

Cheers!

@adamsilverstein:

Great idea, love it! Curious how you came to the realization that the mime type check call was slow/expensive? Did you see it in a trace somewhere?

Was alerted to the issue while checkout out the XHProf flamegraphs demo from @joehoyle here:https://x.com/joe_hoyle/status/1806347618185875819

@felixarntz:

This is a good idea IMO, though at first glance I think this cache would apply at a very low level.

That's a good observation. I was trying to specifically target this one known issue that was impacting the editor. However, I think caching at a higher level makes sense. I've updated this PR to cache the results of the wp_image_editor_supports check, which is the function that is that causes _wp_image_editor_choose to be called most often (4 times during a normal editor load).

With this PR applied, _wp_image_editor_choose never gets called with a warm cache.

I've added a new global cache group, called 'image_editor', and store this value to a wp_image_editor_supports cache key, with a TTL of 1 day.

Thanks @felixarntz. Good point about the implementation filter. Also, I was originally thinking just caching the supports check would be safer, but caching the implementation does have broader potential impact. I've updated this PR to move the cache to _wp_image_editor_choose() and the results are looking pretty good.

Here's my local profile of the /wp-admin/post-new.php page before and after the cache is warmed. Almost all of the savings is still coming from avoiding calls to WP_Image_Editor_Imagick::supports_mime_type but this is a bit broader and should have a noticeable impact on editor loading times on systems with a persistent object cache and may also speed up image uploads.

## Cold cache

## Warm cache

Thanks @felixarntz. Good point about the implementation filter. Also, I was originally thinking just caching the supports check would be safer, but caching the implementation does have broader potential impact. I've updated this PR to move the cache to _wp_image_editor_choose() and the results are looking pretty good.

Here's my local profile of the /wp-admin/post-new.php page before and after the cache is warmed. Almost all of the savings is still coming from avoiding calls to WP_Image_Editor_Imagick::supports_mime_type but this is a bit broader and should have a noticeable impact on editor loading times on systems with a persistent object cache and may also speed up image uploads.

## Cold cache

## Warm cache

[joemcgill]

In 59189:

Media: Cache the results of _wp_image_editor_choose.

This saves the WP_Image_Editor implementation that supports the queried options to a cache to avoid performing redundant compatibility checks, which can be expensive. For example, WP_Image_Editor_Imagick::supports_mime_type() can get called in the editor multiple times to determine which image formats can be supported during wp_plupload_default_settings().

With this cache, the support will be stored for 1 day, speeding up loading times for the editor. This also introduces a new global caching group, image_editor to manage any subsequent caches that are related to image editor optimizations.

Props joemcgill, desrosj, westonruter, flixos90, adamsilverstein, mukesh27, joehoyle.
Fixes #61532.

Committed in https://core.trac.wordpress.org/changeset/59189.