Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.6k
[Translation] [FrameworkBundle] Translation: Optimized loading (lazy loading) of domains#2570
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
| * @return Boolean | ||
| * | ||
| */ | ||
| public function hasDomain($domain); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
We cannot add this method to this interface as it is marked with an@api tag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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 CSFixing CSMinor optimalisationupdated unit tests for new dumpersresolve conflict with @api tagsfix CSTranslation domain loading memory optimalisationremoved unused variablefixed 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 ? |
litek commentedNov 5, 2012
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. |
ghost commentedMay 1, 2015
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.