Gavin Smith <gavinsmith0...@gmail.com> writes:
> On Sun, Feb 1, 2015 at 10:07 AM, Daiki Ueno <u...@gnu.org> wrote:
>> Eli Zaretskii <e...@gnu.org> writes:
>>
>>> Perhaps we could call _configthreadlocale to see if the value of
>>> setlocale can be cached?
>>
>> Yes, but then we would need to hook setlocale to invalidate the cache,
>> and currently the setlocale module is not listed in the dependencies of
>> localcharset. I'm wondering if it is worth adding the dependency for
>> this particular performance problem. Perhaps it might be easier to add
>> a new API to localcharset for single-threaded / single-locale consumer.
>
> Here's a simple solution. The caller of the new function would call
> locale_encoding themselves and save the result. Maybe somebody will
> have a better idea. If this is too specialized to go into gnulib,
> would it be easy for a project to use its own replacement functions
> instead of the ones from gnulib?
> int
> ! wcwidth_given_encoding (wchar_t wc, const char *encoding)
This will make consumers to replace all wcwidth calls with this new
function, which is good as a short-term solution and breaks consistency
with other similar functions, like mbrtowc.
By the above, I meant to add a new API to localcharset instead of
wcwidth, something like:
static const char *cached_locale_charset;
void
locale_charset_single_init (void)
{
#ifdef WINDOWS_NATIVE
locale_charset_cached = locale_charset ();
#endif
}
and in locale_charset, always use locale_charset_cached if it is set.
Then you could invoke locale_charset_thread_unsafe at the beginning of
your program. Once this workaround becomes unnecessary, we could make
this function nop.
Regards,
--
Daiki Ueno
