User tests: Successful: Unsuccessful:
Add a caching layer to the languageHelper::parseIniFile method.
Benchmark the function on within the system is not easy the the performance gain is in about 1,5 to 20ms depending on language size and server configuration.
My benchmark on this method only for the backend dashboard had the following results.
Without patch: 2,6-3.0ms
With patch cold cache: 7,6-11ms
With patch warm cache: 0.3-1.11ms
Means a performance gain of 130% to 900% per page load (for language loading).
Using a synthetic 1mb big ini file (35k lines) the following benchmarks apply:
Without patch: 14,6-25,2ms
With patch cold cache: 32,9-34,5ms
With patch warm cache: 0.5-0,9ms
Means a performance gain of 1500% to 5000% per page load (for language loading).
The Benchmark are taken on a Webserver with production load so might be
The results depend heavily on the server configuration and benefits if opcache is used (which is usually active since a couple of years on most(all) hosting providers).
The cache automatically invalidates it's self as soon as the ini file has a new modification timestamp.
Please select:
Documentation link for docs.joomla.org:
No documentation changes for docs.joomla.org needed
Pull Request link for manual.joomla.org:
No documentation changes for manual.joomla.org needed
Status | New | ⇒ | Pending |
Category | ⇒ | Libraries |
overrides are also ini files, the caching depends on the modification time of the ini file and will automatically create a new cache based on it.
Labels |
Added:
PR-6.0-dev
|
I have tested this item 🔴 unsuccessfully on 4a7a88c
Applied the PR and no language values are loaded - only constants
Enabled language debug
Warning
: foreach() argument must be of type array|object, string given in
D:\repos\j6\plugins\system\debug\src\DataCollector\LanguageErrorsCollector.php
on line
132
funny, because actually the error collector function is broken, can you please.
can you please test 2 things (because I can't replicate it).
first move this line out of the try block, so the exception is not cached and you can see it.
second add [] around the text string
$this->errorfiles[$fileName] = ['PHP parser errors :' . $e->getMessage()];
then your error message shouldn't be warning anymore
third be sure to use the latest version from the "Preserve directory structure" or later commit, since I fixed the that frontend languages are used in backend and vis-a-vis.
I have no windows to test, but hope my change fixed it.
That change worked.
tested that overrides still work
tested site and admin
tested plugin that has language files in the plugin and not the main languages folder eg plg_sampledate_testing
Not tested any performance changes
I have tested this item ✅ successfully on 3acc14c
Reading and parsing a json file is faster.
like json_decode(file_get_contents('administrator/cache/language/administrator-language-en-GB-lib_joomla.ini.1743321429.json'),true);
about 30% on my stystem
Reading and parsing a json file is faster.
like json_decode(file_get_contents('administrator/cache/language/administrator-language-en-GB-lib_joomla.ini.1743321429.json'),true);
about 30% on my stystem
can you please show me you measurements, because my test says it's about 8-10 times slower using json for empty frontpage and using a 1mb ini files it's 80-100 times slower.
Hi,
I found the difference: php is a lot faster with opcache enabled. Without opache json.
So the caching strategy should depend on the opcache setting to makeit fancy?
tested on 52 language files on a (almost) clean j6 site.
opache on:
J: 2528880
A: 150734
J: 2629746
A: 141746
J: 2793574
A: 159460
J: 2343749
A: 160488
J: 2136911
A: 112294
J: 2428274
A: 131338
J: 2236474
A: 122881
J: 2356152
A: 136126
J: 2465985
A: 122388
opache off:
J: 3127872
A: 7223167
J: 3041450
A: 6905625
J: 3241212
A: 7150972
J: 3058796
A: 7086077
J: 3219969
A: 7078478
J: 3025679
A: 6968267
J: 3046686
A: 7132398
J: 3202466
A: 6967631
J: 2978589
A: 7161319
KISS, if you don't use opcache you don't care about performance so we shouldn't blow up our codebase for nothing.
I have tested this item ✅ successfully on 3acc14c
I have successfully tested this on 2 sites: non multi-lingual and 1 multi-lingual.
I can honestly say I saw consistently faster speeds however the speed improvement varied from quite a bit from 10% - 26% - I did the battery of test 5 times to get a sense but the large difference I assume comes from 1. the fact that caching is complex and 2. I have fast hosting so the speed difference would be small. Either way I trust you guys! :)
Status | Pending | ⇒ | Ready to Commit |
RTC
Labels |
Added:
RTC
|
Just curious, why did you not use the Joomla cache API?
because it's too slow, the caching api would save the content to a file or database or apcu or whatever, which means it needs to load it (over tcp as worse case) and then decode the string and transform it into an array.
when doing it directly it uses the opcache in memory and in binary/compiled format. But for this to work you need a file on the filesystem.
There is no faster format then opcache, normally I would say yes use the caching api from joomla but since it's a very specific case (it's saved in the "wrong" format ini) I have chosen this way.
Above you see the variant with json which is slower, I would expect similar results for the joomla caching layer.
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2025-04-29 11:38:58 |
Closed_By | ⇒ | softforge |
Thank you @HLeithner for the work on this and @brianteeman for testing and helping with the solution and thanks to the other testers who got involved.
What about when an override is created?