load_textdomain() cached for the better boot-up performance

[itmapl]

This is a simple caching strategy for MO files being used for languages other than en_US. The en_US causes an exit at that condition ​https://github.com/WordPress/WordPress/blob/master/wp-includes/l10n.php#L756 so actually the caching is no needed for this case.

The caching gives ~21% better (indirect) performance according to the tests with results as following (see the comment): ​https://github.com/itma/WordPress/commit/cb1e3d26d436ce5074c4f0064713f6d498f0fa57?fbclid=IwAR2oxg6gWuQKkbCGOcdQLzjKiF7yfWeEk2naBR8yoReejs9RN9uJb6Jb-qw#commitcomment-76640993

The files changed are listed here (not too much):

​https://github.com/WordPress/WordPress/pull/600

Cheers,
Andrzej

[itmapl]

I was thinking a bit about the approach with files to cache the translation, ended up with thought that the approach does not fit the WP's simplicity. I changed it to using the native Transients API. Results are the same (still better, even better that caching with files like I did before).

Here is the file, and the commit I made:

​https://github.com/WordPress/WordPress/blob/fc892a0863abc7580441b4ed4bfc21a212bcf64d/wp-includes/l10n.php

[itmapl]

Diagram produced by KCachegrind shows the request made on a fresh WP instance. Pay attention to the branch starting from load_default_textdomain.

[itmapl]

The diagram presents the state after optimization. load_default_textdomain has been totally taken off during the next request after caching MO object, finally speeds up the time to boot-up the WP on the http request.

[SergeyBiryukov]

Hi there, welcome to WordPress Trac! Thanks for the ticket.

Just moving this to the correct component.

These tickets seem related: #17268, #32052.

[itmapl]

Yup, these tickets are totally related. Even the approach to solve the problem is the same. I suggest choosing one of the proposed solutions. https://core.trac.wordpress.org/ticket/17268 contains a proof of concept for the plugin nevertheless the plugin has been disabled as it applies to the core files.

What I've been thinking about is adding a cache clear after a language update via admin. This will give the way a user doesn't have to care about what is cached (and all the stuff to manage that) referring to l10n etc. All will be done under the hood.

The change to the core WP implementation will significally decrease the memory usage, and speeds-up the boot-up time so I think it is worth considering keeping in mind that Google cares about that.

[itmapl]

@SergeyBiryukov yet another approach to the problem. Probably the most fit with the WP core. ​https://github.com/WordPress/WordPress/compare/master...itma:WordPress:l10n-custom-action-filter

By adding an action hook and filter hook any plugin can hook into that and process it on its own way. I prepared a test plugin for checking the approach - seems working as supposed ​https://github.com/itma/WP_LocaleCache_Plugin/blob/main/locale_cache_plugin.php.

That way we are getting off all problems referring to manage any caching made by WP like it was in the previous proposals.

[adamsilverstein]

Milestoning this for 6.1, this would be a great improvement to land in this release

[adamsilverstein]

Hi @itmapl - thanks for opening this ticket! load_textdomain caching seems like an important and worthwhile performance improvement we should try to land and the scope seems more contained than other tickets! I have some questions!

Reviewing the patch you proposed in ​https://github.com/WordPress/WordPress/pull/600 both load_textdomain_from_cache & cache_textdomain use file based caching. If I understand this correctly, the goal is to have to load and process the language files once, so a persistent cache makes sense. I'm not sure how large the data is and if maybe using the core Transient API would be better here? Ideally using an existing caching API is preferable over writing files directly which might not work as expected.

What I've been thinking about is adding a cache clear after a language update via admin. This will give the way a user doesn't have to care about what is cached (and all the stuff to manage that) referring to l10n etc. All will be done under the hood.

Caches would also need to get updated on core, plugin and theme updates where strings could potentially change. If core doesn't already have a "languages_updated" action maybe consider adding one.

yet another approach to the problem. Probably the most fit with the WP core. ​https://github.com/WordPress/WordPress/compare/master...itma:WordPress:l10n-custom-action-filter

By adding an action hook and filter hook any plugin can hook into that and process it on its own way.

I feel like the caching itself belongs in core if possible! Once we have that, For hooks, I definitely see value in a hook for "languages updated" and a way for developers to disable the caching entirely for their use case

The change to the core WP implementation will significally decrease the memory usage, and speeds-up the boot-up time

It would be nice to add basic profiling information to the ticket with some before/after numbers for page load time and memory consumption so that we can proceed with a better understanding of the implications of the change. Let me know if you want some help with that!

[itmapl]

If I understand this correctly, the goal is to have to load and process the language files >once, so a persistent cache makes sense. I'm not sure how large the data is and if maybe using >the core Transient API would be better here? Ideally using an existing caching API is >preferable over writing files directly which might not work as expected.

Definitely correct, and yes Transient API fits much better in that case. Here ​https://github.com/itma/WordPress/commits/l10n-caching-transient-api/wp-includes/l10n.php I've been working on the ticket, and made the first step porting the code into Transient API.

Caches would also need to get updated on core, plugin and theme updates where strings could >potentially change. If core doesn't already have a "languages_updated" action maybe consider >adding one.

Good catch, I will follow that.

I feel like the caching itself belongs in core if possible! Once we have that, For hooks, I >definitely see value in a hook for "languages updated" and a way for developers to disable the >caching entirely for their use case

Definitely good idea! Will follow that.

It would be nice to add basic profiling information to the ticket with some before/after
numbers for page load time and memory consumption so that we can proceed with a better
understanding of the implications of the change. Let me know if you want some help with that!

Sure, numbers are always welcomed. At the end I will prepare a little sum up. For now I need nothing from you, just have to take hands dirty, and dive into that ticket ;-)

[itmapl]

@adamsilverstein take a look at this ​https://github.com/WordPress/WordPress/pull/610/files

That could be the next point to discuss on. Details for the pull request are described on github. If you've any other proposals let me know. Personally I don't think it is the correct place to define a const here ​https://github.com/WordPress/WordPress/pull/610/files#diff-b82e2f553f0312265025fa0dfbb40ed9ec3da68063b37bde8ed44a8f1ec7b2bfR3, also calling the hooks below does't fit the place in my opinion BUT I count on you, and what you say about that.

[swissspidy]

Especially given the logical proposal to use object cache or transients caching, this feels like a duplicate of #32052, and I'd like to echo my recent comment there with some concerns. I suggest consolidating the tickets and doing a more thorough analysis of various approaches.