On "Optimisation issues with glibc-2.2 and LANG=???"



Dear All,
	Last month I sent an e-mail to glibc-bugs on a performance
issue with glibc and gettext. When the user sets the LANG variable,
every program that is run has to do some extra work. The e-mail was
to identify any possible bottlenecks.
	My primary concern was that in distributions of Linux (for example
RH7.0), the value of LANG does not have an "optimised" value.
For Greek, if you set LANG to "greek" and you run a program,
the program tries to find the message catalogs in a
	"..../el_GR.ISO-8859-7/..." directory first but fails
	"..../el_GR.iso88597/..." directory but it fails
	"..../el_GR/..." directory and it finally succeeds.

I tried to get some figures on the average delay of such unoptimised
configuration and the result was some miliseconds of delay. The e-mail
 mentioned, which is at

	http://mail.gnu.org/pipermail/bug-glibc/2001-January/002468.html

stresses (unfortunately) on this issue only.

Why do I say "only"? Because doing tests comparing
	a. LANG=C
	b. LANG=greek (or other language),
there was a big difference (also mentioned in the above URL).

Doing on the fly requests for translated strings looks to be a
non-negligable bottleneck.

The reason that I mention this issue is that in the future, it might
be a good idea to add functionality to gettext so that during the
compilation of packages, a different default language can be selected
and these messages will be put in the binaries instead of english.

My 5 drachmas, (smallest denomination in circulation currently)
simos





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]