Problem/Motivation
Currently importing of .po files for projects could take unacceptable about of time.
Proposed resolution
I have found that problem related to implementation of locale_translation_status_save();
This could be solved by this changes:
function locale_translation_status_save($project, $langcode, $type, $data) {
// Load the translation status or build it if not already available.
module_load_include('translation.inc', 'locale');
- $status = locale_translation_get_status();
+ $status = locale_translation_get_status([$project]);
if (empty($status)) {
$projects = locale_translation_get_projects([$project]);
if (isset($projects[$project])) {Remaining tasks
Don't see for now.
User interface changes
No changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | locale_translation_import_performance-3074765-22.patch | 756 bytes | Ankit.Gupta |
| #19 | locale_translation_import_performance-3074765-19.patch | 637 bytes | dxvargas |
| #3 | locale_translation_import_performance-3074765-3.patch | 531 bytes | chewie |
Comments
Comment #2
chewie commentedComment #3
chewie commentedComment #4
chewie commentedComment #5
chewie commentedAdded related issue
Comment #6
chewie commentedComment #7
denes.szabo commentedWhat do you mean "unacceptable about of time"? How do you calculate the time? How much speed (time) you gained?
Why your solution solve the problem?
Comment #8
chewie commentedInitially this issue was detected by executing drush command oe-multilingual:import-local-translations of opensource project https://github.com/openeuropa/oe_multilingual (version: 1.1.1).
I didn't check but probably performance issue could be also reproducible by standard drush command: locale:import.
Comment #10
sutharsan commentedI think to remember, from when I wrote this code, that this call in on purpose. I think that there were situations when the list of available projects did not initialize, this may have been a way to overcome that. But that was 7 years ago... I may be wrong.
I think Denes.Szabo's questions are sensible and should be answered before we proceed with a solution.
Comment #13
spadxiii commentedI ran across this issue as well. Importing the translations would take up to 35 minutes for a single site.
Some info about our site: it uses drupal 8, has about 100 modules enabled, and has 7 languages enabled. It is configured to only look for translations in local files and not download those (as they are downloaded locally). The translations files exist for only 2 of these languages (EN and NL).
Without this change, the method `locale_translation_status_save()` would take about 4.5-4.8 seconds to complete, per project, per language. So a total of about 32-35 seconds per project.
With this change, this was a little bit faster: per project, the first language took 45-50 ms and the languages after took less than 10ms. So a total of about 100-120 ms per project.
I did the quick benchmark by adding a few Timer::start and Timer::read in `locale_translation_check_projects_local()`. This method is called when doing a drush locale:check.
I'm setting this back to needs review, so others will have a look as well :)
Comment #16
heddnre #10, unacceptable is 45 minutes on one site to 2 hours on another during site install. If this brings that down to 5,10 15 minutes, that is a way more acceptable timeframe.
Comment #17
dxvargas commentedThe proposed patch #3 makes a huge difference. Installation time came down from +20m to -10m.
I'll mark it as RTBC.
Because of https://www.drupal.org/project/drupal/issues/3150185, I wonder if this one's priority should be considered major.
Comment #18
quietone commentedThis is testing a patch on Drupal 8.7 and Drupal 8 is End of Life. This needs a patch for 10.0.x.
Comment #19
dxvargas commentedRight, here it is the equivalent patch for core 10!
Comment #20
heddnI tested this on a 40+ language site with tons of translations in each of the languages and 86 contrib modules. WAY faster install times. And even running the drush command to pull down translations is a LOT faster.
RTBC++
Comment #22
Ankit.Gupta commentedReroll the patch #19 with Drupal 10.0.x
Comment #23
dxvargas commentedPatch in #22 is basically the same as in #19 which was RTBC.
It is good, I put the ticket back into RTBC.
It would be nice to have this merged, since it brings a good performance enhancement.
Comment #25
catchCommitted/pushed to 10.1.x and cherry-picked back to 9.4.x, nice find and thanks for the various manual testing everyone.
Comment #27
uv516 commentedI am using Drupal 10.4.6 and patch #22 is implemented.
Despite that, the site still takes a VERY LONG time to search and save translations.