Re: Call to locale_charset within wcwidth

[Eli Zaretskii]

> From: Daiki Ueno <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Sun, 01 Feb 2015 03:52:20 +0900
> 
> Eli Zaretskii <address@hidden> 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".