Open Krisell opened 5 years ago
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?
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.
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!
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.
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).
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
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?