[Translation] [FrameworkBundle] Translation: Optimized loading (lazy loading) of domains #2570
Conversation
| * @return Boolean | ||
| * | ||
| */ | ||
| public function hasDomain($domain); |
There was a problem hiding this comment.
We cannot add this method to this interface as it is marked with an @api tag.
There was a problem hiding this comment.
Fixed, thanks.
|
@pulzarraider is this PR still valid ? If yes, please rebase your branch. It conflicts with master because of the move of the tests. If no, please close it |
|
@stof Yes, it's valid. I will update it in the next few days. |
Fixing CS Fixing CS Minor optimalisation updated unit tests for new dumpers resolve conflict with @api tags fix CS Translation domain loading memory optimalisation removed unused variable fixed conflict
|
@stof Rebase done, conflicts fixed. |
|
Any new on this? |
|
@fabpot should this PR be updated to be merged into 2.2 or do you think it should be rejected and closed ? |
|
I've been using the Translation component separately with Silex, so no integrated caching at all. My solution was to create a CachedLoader wrapper. I'm not familiar with the inner workings of Symfony, but maybe that could work here as well? It would definitely be an improvement to the standalone translation component at least. |
|
I'm not convinced that this has a real performance impact. It would help if we had some simple benchmarks. |
|
@fabpot The performance and memory consumption will depend on the number of translations in those domains, that are not used in a request. If the number of translations is small, it's OK to let them together in one file, because effect on performance is negligible and searching+loading+compiling+executing file costs something, too. But it will change if there exist hundreds or thousands of translations in different domains. For example, I find completely unnecessary to automatically load translations of Maybe we can make compromise solution and let small domains to be cached together in one file (to avoid existence of many small files in cache) and bigger domains store in cache separately (each domain in one file). This will not help webpage with many translations wrapped into a lot of domains, but I think that such cases are not frequent. Anyway, I will update this PR for latest Symfony version and create some benchmarks in the next recent days with different number of translations to be sure my PR will not slow down the framework. |
|
@pulzarraider Can you continue work on the PR, please? |
|
@Koc I am a bit busy atm, but I will continue working on this PR. |
|
ping @pulzarraider |
|
one more ping @pulzarraider ;) |
|
ping again @pulzarraider |
|
I will continue working on this PR next week. |
|
A configurable threshold for merging smaller domains together would be great. |
|
ping @pulzarraider |
|
@aitboudad what do you think of this one? |
|
OK you're on it, I just read the linked PR :) |
|
Closing |
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes (tests updated)
Fixes the following tickets: -
Website can have hundreds of messages in each domain. Some domains (and their translations) are not used during different requests (for example "admin" domain and their messages will not be used on public pages, "validation" domain will not be used until validating some entities/processing forms). This PR changes the way how messages are cached. Instead of storing all domains in one file (catalogue.en.php), domains are saved separately (/en/messages.php, /en/validators.php, etc.) and they are processing and loaded into memory only when they are required (to translate some text). This will optimize memory usage.