[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: performance bug of `wc -m` on macOS

From: Pádraig Brady
Subject: Re: performance bug of `wc -m` on macOS
Date: Sun, 20 May 2018 20:07:05 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

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:

As for further locale_charset improvements, I linked previous speedup attempts
with thread local storage caching at:

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]