RE: Performance issue of GetText library.

[Damjan Skvarc]

Hi Bruno 

and thanks for a quick answer, despite it doesn't help me much :((.
In the meanwhile I have clarified the situation and I have found 
a hacker, who hacked the code in order to improve the already 
known performance issue.  Therefore I have to appologise myself
by disturbing you within your work (excellent I believe) and asking
you about the nonexisting change in the original code.

Anyway, there exist a performance issue in the your code and
in our case we will keep the hacked code, since we are sure
that the environment variable LC_ALL or similars are not changed
during the execution of our application. Btw, on Windows platform
we do not have the second alternative (you have mentioned bellow)
to change the environment variable. This is because the _putenv() 
function allocates its own internal buffer and copies into it the 
specified string. This is the difference between the HP-UX, since 
there only a pointer to the specified buffer is remembered. 
Therefore we have a better control over changing the environment 
settings.

Again, thanks for the answer and best regards.
Damjan.




> -----Original Message-----
> From: Bruno Haible [mailto:address@hidden 
> Sent: 2. junij 2004 13:01
> To: Damjan Skvarc; address@hidden
> Cc: Borut Razem; address@hidden
> Subject: Re: Performance issue of GetText library.
> 
> 
> 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
>