Make WordPress Core

Opened 2 years ago

Closed 21 months ago

#56051 closed enhancement (duplicate)

load_textdomain() cached for the better boot-up performance

Reported by: itmapl's profile itmapl Owned by: adamsilverstein's profile adamsilverstein
Milestone: Priority: normal
Severity: normal Version:
Component: I18N Keywords: needs-refresh
Focuses: performance Cc:

Description

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

Attachments (2)

before_opt_textload.png (174.2 KB) - added by itmapl 2 years ago.
Diagram produced by KCachegrind shows the request made on a fresh WP instance. Pay attention to the branch starting from load_default_textdomain.
after_opt_textload.png (129.5 KB) - added by itmapl 2 years ago.
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.

Download all attachments as: .zip

Change History (15)

#1 @itmapl
2 years ago

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

Last edited 2 years ago by itmapl (previous) (diff)

@itmapl
2 years ago

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

@itmapl
2 years ago

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.

This ticket was mentioned in Slack in #core by itmapl. View the logs.


2 years ago

#3 @SergeyBiryukov
2 years ago

  • Component changed from Text Changes to I18N

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

Just moving this to the correct component.

These tickets seem related: #17268, #32052.

#4 @itmapl
2 years ago

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.

#5 @itmapl
2 years ago

@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.

#6 @adamsilverstein
22 months ago

  • Milestone changed from Awaiting Review to 6.1

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

#7 @adamsilverstein
22 months ago

  • Keywords needs-refresh added

#8 follow-up: @adamsilverstein
22 months ago

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!

#9 @adamsilverstein
22 months ago

  • Owner set to adamsilverstein
  • Status changed from new to assigned

#10 in reply to: ↑ 8 @itmapl
22 months ago

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 ;-)

Last edited 22 months ago by itmapl (previous) (diff)

#11 @itmapl
22 months ago

@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.

Last edited 22 months ago by itmapl (previous) (diff)

#12 @johnbillion
21 months ago

  • Version trunk deleted

#13 @swissspidy
21 months ago

  • Milestone 6.1 deleted
  • Resolution set to duplicate
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.