[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wcwidth replacement problems
From: |
Alexander V. Lukyanov |
Subject: |
Re: wcwidth replacement problems |
Date: |
Tue, 26 Aug 2008 14:32:12 +0400 |
User-agent: |
Mutt/1.5.11 |
On Tue, Aug 26, 2008 at 09:32:32AM +0200, Bruno Haible wrote:
> Alexander V. Lukyanov wrote:
> > Let's measure it.
> >
> > $ time ./wcwidth-solaris
> > wcwidth(0x2022)=2
> >
> > real 0m2.205s
> > user 0m2.200s
> > sys 0m0.000s
> >
> > $ time ./wcwidth-rpl
> > wcwidth(0x2022)=1
> >
> > real 0m55.477s
> > user 0m55.350s
> > sys 0m0.000s
> >
> > $ time ./wcwidth-mk
> > wcwidth(0x2022)=1
> >
> > real 0m1.944s
> > user 0m1.940s
> > sys 0m0.010s
>
> This is not a fair comparison: wcwidth-mk works only in UTF-8 locales,
> whereas wcwidth() from the system and from gnulib return the right result
> in all locales. The test whether the locale encoding is UTF-8 is precisely
> what takes up most time in the gnulib replacement.
Ok. Would you accept this patch, which caches charset properties?
BTW, it also fixes a bug - cjk case could not ever be executed before.
$ time ./wcwidth-rpl1
wcwidth(0x2022)=1
real 0m4.160s
user 0m4.150s
sys 0m0.010s
Worse than Solaris native wcwidth (nl_langinfo+strncmp costs), but still 13
times faster than before.
--
Alexander.
diff
Description: Text document