> From: Daiki Ueno <u...@gnu.org> > Cc: gavinsmith0...@gmail.com, bug-gnulib@gnu.org > Date: Sun, 01 Feb 2015 03:52:20 +0900 > > Eli Zaretskii <e...@gnu.org> writes: > > > Thanks. This improves things, but unfortunately not enough. The > > reason is that call to setlocale at the beginning of locale_charset, > > which is always made. If I replace that call with a constant string, > > I get a 20-fold speedup, and the display of large nodes in the Info > > reader becomes instantaneous, as it was in v5.2. > > > Here are my timings, measured on Windows XPSP3, after enlarging the > > loop count to 2000000, to get the fastest version out of the > > quantization error of the system clock: > > Thanks for testing. IMO, the locale_charset call in wcwidth (and > mbrtowc) and the setlocale call in locale_charset are inevitable to > support per-thread locales, unless we are going to add a new API.
I agree. But note that per-thread locale support in setlocale requires on Windows a separate call to _configthreadlocale (see https://msdn.microsoft.com/en-us/library/26c0tb7x.aspx), which AFAIU is not supported by mingw.org's MinGW runtime (MinGW64 seems to support it, although threads must be started with CRT functions like _beginthreadex, not with CreateThread etc.). So the default is for setlocale to affect the global per-process locale anyway. Perhaps we could call _configthreadlocale to see if the value of setlocale can be cached? > However, I missed the fact that setlocale (LC_ALL, NULL) returns a > concatenation of all category values on Windows. Perhaps the overhead > could be halved by omitting the second call of setlocale (i.e. moving > the cache lookup above setlocale (LC_CTYPE, ...))? Yes, you can halve the time, but not in the usual case, where the second call to setlocale is not done. That call is only needed if some of the categories use a different locale from others; otherwise the value returned by setlocale (LC_ALL, NULL) is a single locale like "English_United States.1252".
