[Proposal] (OP)Cache mix-manifest and translation JSON files

[Krisell]

Currently, the first call of each request to the global mix() helper function will read the contents of mix-manifest.json and JSON-decode that into a php array.

A simple artisan command, mix:cache, could read this file and store a php-cache which can be read in the same way as cached configs ($manifest = require $cachedManifest).

This is faster since opcache can be used and no parsing is needed.

The actual performance increase depends on how fast the filesystem is, but it is admittedly quite small. My initial tests point at around 0.1 ms (~1 % for simple views). The only reason I'm considering this is because the changes are small and the implications for the user is minimal (an optional addition of mix:cache to the current list of deploy-commands).

Has this been up for discussion before?

[Krisell]

The translation files are also stored as JSON and could be treated in the same way. Initial tests show reductions of 1 ms, i.e. much more than for the manifest-file, but this of course depends on the size of the translation-file (my test file is quite large but not huge).

I will make more measurements, but the same question as above applies here as well, has this been discussed before?

[hubertnnn]

I like the mix:cache, but I dont think the gains are big enough to mitigate the extra cache file that need to be checked and processed.

The translations on the other hand, I do love. I am thinking not only about converting json files to php (I personally dont like json translations and prefer php ones), but the entire translator object could be compiled after loading all languages and serialized. Cant wait for your measurements, but I believe that for a big project (thousands of translation lines, and support for multiple languages) this can make a decent gain.

[Krisell]

I have looked more into caching JSON translation files, and I have now published a package which achieves this:

https://github.com/Krisell/laravel-translation-json-cache https://packagist.org/packages/krisell/laravel-translation-json-cache

Notice that the caching functionality is completely opt-in – only installing the package doesn't activate the functionality (since the caching could be irritating in local development).

See the readme for some measurements, and additional measurements are highly welcome.

Also, I mostly have experience with the JSON-approach, so I have not looked into your ideas @hubertnnn, but they do sound interesting!

[hubertnnn]

I think rather than using an env variable you could use the same approach as in laravel itself: Create a file in bootstrap/cache/translations.php when calling artisan translations:cache and use it if file exists. This way it would work similar to route:cache, config:cache, view:cache etc.

[Krisell]

Yeah you're probably right. I thought it was a nice feature to not have to run any command at all during deployment (since the first request would generate the file), but that does make it inconsistent with the other caching features.

I'll also look into if it makes sense to keep one file per language (to keep the file small), or one file for all cached language data (to always load the same file).

[Krisell]

v2.0.0 is now released after the great suggestion by @hubertnnn The JSON-caching now works the same was as route and config-caching (a command to create the cache files).

https://packagist.org/packages/krisell/laravel-translation-json-cache