Re: Call to locale_charset within wcwidth

[Daiki Ueno]

Gavin Smith <address@hidden> writes:

> On Sun, Feb 1, 2015 at 10:07 AM, Daiki Ueno <address@hidden> wrote:
>> Eli Zaretskii <address@hidden> 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