Difference between other mo cache plugins

Hello,

I didn’t know these 2 plugins. I had a (very) quick look and dor what I understand,they both use the MO objects from WordPress and cache them. So they benefit only to sites using persistent cache.

DynaMo was inspired by another plugin: WP Performance Pack which doesn’t seem to be maintained anymore.

DynaMo replaces MO objects from WordPress and offers two different ways to load MO files.
– The first one introduced in v1.0 doesn’t load the file completely as WordPress does. It loads only translations when they are needed. This is more efficient for big translations files. As files are not loaded completely, this is not compatible with persistent cache.
– The second one introduced in v1.1 is closer to the plugins you linked to, as it takes profit of the persistent cache. As with the MO object from WordPress, all translations are loaded. The goal however was to have a more memory efficient and more performant class to store translations.

The second method is used when a persistent cache is detected. The first method is used otherwhise. All sites can improve their performance.

It’s not included in Polylang, because most sites are not multilingual. However, even if a site uses only one (non en_US) language it can take profit of DynaMo.

@chouby Thanks for the answers, I saw your plugin mentioned in the https://github.com/WordPress/performance/ but I also saw a benchmark between different solutions of opcache, object cache etc but cannot find it right now.

My only reason to not switch from either of those is they have menu cache also which is another request similar this which can be cached. Doesn’t fit in this plugin of yours as it focus only on mo and language cache.

It’s not included in Polylang, because most sites are not multilingual. However, even if a site uses only one (non en_US) language it can take profit of DynaMo.

Right that make sense why!

– The first one introduced in v1.0 doesn’t load the file completely as WordPress does. It loads only translations when they are needed. This is more efficient for big translations files. As files are not loaded completely, this is not compatible with persistent cache.

Okay so this is the second best for users without object cache but there is a solution for them to improve. Do you mean it ony load when its used but it wont compile a used string mo files? It will still load the whole mo file containing all strings once needed? And it will only load for the language needed?

– The second one introduced in v1.1 is closer to the plugins you linked to, as it takes profit of the persistent cache. As with the MO object from WordPress, all translations are loaded. The goal however was to have a more memory efficient and more performant class to store translations.`

Okay but in the mo persistent cache will it load from cache only or will it also only load the language that is requested and used. So we only load fr_FR when requesting /fr/? If not today is that possible? Would be ideal to only cache and serve the used strings. Is this possible you think or technical limitations here?

So you are not done and you still looking for ways that are in line with the goal by it being memory efficient and more performant class store translations?

Does it invalidate the cache in similar ways like the other plugins mentioned in this thread? How can we validate the mo cache is working as it should? Might be some good FAQ to add once you have time.

• This reply was modified 2 years, 4 months ago by Rookie.

When WordPress loads the MO file, it may read and store let say 3000 strings even if only one is used for translation. However MO files are purposedly structured to offer a way to find where the string is stored. So there’s no need to read the complete file to find one string. That’s what the first method does. Partial read of the file. It’s very efficient when you need to translate only a few strings from a big translations file.

As for the second method, only used translations files are read from the cache. But I believe it’s the case for others too. Probably all similar plugins hook to the WordPress translation file load function. So no useless file should be loaded.

I intentionnaly chose to store the complete file in the cache. That way only the cache is used. Caching only used strings would mean that we would read the file more often to update the cache when the string is not present. It may depend on the install, on the plugin, but I feared it could be less efficient.

The cache is invalidated every 12 hours. You can control this delay with a filter. It’s also invalidated at each update, whatever this update is (WordPress, plugin, theme, translation).

@chouby Would not phasing only used string and caching those be the ultimate solution?

I see use of both cache is great but we might only use 5-10% of the strings.