GNU gettext - Bugs: bug #58006, Massive slow down due to slow...
You are not allowed to post comments on this tracker with your current authentication level.
bug #58006: Massive slow down due to slow get_env because libintl doesn't cache untranslated strings
Submitter: | Jianxiang Wang <qrox> | ||
Submitted: | Tue 17 Mar 2020 04:06:08 PM UTC | ||
Category: | End-user / runtime | Severity: | 3 - Normal |
Item Group: | None | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
No changes have been made to this item
Powered by Savane 3.13-4448.
Corresponding source code
We're using `gettext/libintl` in a text-intensive project (Cataclysm:DDA, to be precise). Since we use English as the source language, we do not compile a .mo file for English. In some of the program's UIs, a large amount of text is translated, processed, and displayed, where I noticed a significant slow down, particularly on MinGW target. Profiling the program showed that `getenv()`, called by `libintl`, took the majority of CPU time (~50%). So I profiled `libintl` and found out it was caused by a caching issue when `libintl` does not find a translation for a source string.
The following are tested on git commit `284d55ec4c24479789b250bdcba9e3782cca2994` of `gettext`.
So, in `libintl_dcigettext`, when a translation is not found (`dcigettext.c:765`), the code to cache translation (`dcigettext.c:816`) is skipped, and the source string is returned without caching (`dcigettext.c:850`). The next time `libintl_dcigettext` is called with the same source string, the whole process of translation lookup happens again, including a call to `getenv("GETTEXT_LOG_UNTRANSLATED")` in `libintl_dcigettext()`, a call to `getenv("LANGUAGE")` in `guess_category_value()`, and several `getenv()` calls in `gl_locale_name_environ()`, which took up the majority of execution time of these functions.
After switching the language of the program to a non-English one, I observed a noticeable performance improvement, which confirmed my theory.
While I think there might be a performance issue with Windows' `getenv()` itself, I think this is also a bug of `libintl` that needs to be fixed.