Re: speeding up `wc -m`

On 21/05/18 11:00, Bruno Haible wrote: > Hi Pádraig, > >> $ yes | head -n10 > mbc.txt >> $ yes 12345678901234567890 | head -n10 > num.txt >> >> = Before >> >> $ time src/wc -m < mbc.txt >> 210 >> real0m0.186s >> >> $ time src/wc -m < num.txt >> 210

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

With the proposed function-pointer-factory changes, I'm seeing this speedup on macOS systems: num mbc Before0.153 0.229 After 0.042 0.112 --- Speedup3.6 2.0 factor The profiler's output now is:

speeding up `wc -m`

Hi Pádraig, > $ yes | head -n10 > mbc.txt > $ yes 12345678901234567890 | head -n10 > num.txt > > = Before > > $ time src/wc -m < mbc.txt > 210 > real0m0.186s > > $ time src/wc -m < num.txt > 210 > real0m0.056s Here's my take on improving th

Re: performance bug of `wc -m` on glibc systems

With the proposed function-pointer-factory changes, I'm seeing this speedup on glibc systems: num mbc Before0.056 0.152 After 0.057 0.089 --- Speedup1.0 1.7 factor Find attached the profiling result. What you can see: - The glibc-compatible re

[PATCH] crypto: omit stream ops Emacs doesn’t need

* lib/md5.c (md5_stream): * lib/sha1.c (sha1_stream): * lib/sha256.c (shaxxx_stream, sha256_stream, sha224_stream): * lib/sha512.c (shaxxx_stream, sha512_stream, sha384_stream): Compile stream functions only if GL_COMPILE_CRYPTO_STREAM is defined. Emacs needs this, as it does not use the stream op

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

Pádraig Brady wrote: > 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 I was now able to get a profiling on macOS (

Re: uc_width and wcwidth optimization

Alexander V. Lukyanov wrote in : > For quite some time I use this locale_charset optimization, which uses > binary search for locale alias resolution. This is a good optimization. I ended up implementing a binary search as well, a