On 20/05/18 18:50, Bruno Haible wrote:
> Pádraig Brady wrote:
>> That suggests we're not replacing
>> wcwidth on this OSX system, and that the system implementation
>> is just very slow, which the attached patch should avoid if possible.
>
> If we have a system where wcwidth is very slow, gnulib could
> override the function with a faster implementation (like it
> already does e.g. for 'strstr'). This is possible here,
> because the wchar_t implementation is known (unlike older
> BSDs and/or Solaris).
>
> However, before we do this, can you please check whether it already
> uses the gnulib replacement or not? ('nm src/wc | grep width')
> On my macOS 10.13 system, it links in rpl_wcwidth, and therefore
> the system's wcwidth performance is irrelevant (because our test
> is running in an UTF-8 locale and therefore rpl_wcwidth calls
> uc_width, never wcwidth).
Yes you're correct.
system wcwidth is not implicated here.
The slow down was attributed to locale_charset().
At least this should be improved in the next coreutils release with:
https://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=214bf85
As for further locale_charset improvements, I linked previous speedup attempts
with thread local storage caching at:
https://lists.gnu.org/archive/html/coreutils/2018-05/msg00046.html
Another approach may be to provide a wcwidth_single() implementation
(similar to unlocked-io.h), that used a static variable to
cache for single threaded apps like wc.
Thanks for benchmarking this.
cheers,
Pádraig
