Re: Performance issue of GetText library.

[Bruno Haible]

Damjan Skvarc wrote:
> We are using the GetText library for a while and
> in version 0.12.1 we have noticed a great decrease in
> performance within GetText library. In certain cases
> the change in GetText library decreases the performance of
> our application for 40%.
>
> After investigation we have found out that the reason for
> the performance dropdown is the following change in a function
> DCIGETTEXT(..) (file dcigettext.c).
>
> The code in version 0.11.5:
> -------------------------------------------------------------------------
>   if (category!=current_category || _nl_msg_cat_cntr!=current_counter)
>   {
>     /* Now determine the symbolic name of CATEGORY and its value.  */
>     categoryname = category_to_name (category);
>     strcpy(cval, guess_category_value (category, categoryname));
>     current_counter = _nl_msg_cat_cntr;
>     current_category = category;
>   }
>   categoryvalue = cval;
> -------------------------------------------------------------------------
>
>
> has been changed in version 0.12.1 into the
> -------------------------------------------------------------------------
>   /* Now determine the symbolic name of CATEGORY and its value.  */
>   categoryname = category_to_name (category);
>   categoryvalue = guess_category_value (category, categoryname);
> -------------------------------------------------------------------------
>
> The problematic code is within a function guess_category_value(), where
> in the worse case the getenv() function is called four times and on
> Windows OS the getenv() function is a very time consuming function.

The first code snippet that you show, with current_category, has never been
in an official gettext release (neither 0.10.40 nor 0.11.5); it must be
a Windows specific performance hack by someone.

This performance hack is also not correct: If the value of the environment
variable (LC_ALL, LANG or similar) changes while the program is running,
the dcigettext() function will not notice it and return a result for the
wrong language. Such a change in the environment variable can happen
  1) through a libc function such as putenv() or setenv(); many applications
     use this function: you can even access it from Emacs Lisp,
  2) through direct modification of a string that was earlier passed to
     putenv().

Because of case 2), at least on POSIX platforms (where getenv() looks at
the strings passed to putenv()), it is impossible to optimize away
getenv() calls without breaking the correctness of gettext().

Windows too has a _putenv() function, therefore I think the same holds
for this platform too.

Bruno