Why don't you just use that data of the width specification from the LC_CTYPE of the current locale? That is probably much faster to get access to, it is just one indexing operation instead of a number of if's. And you get free upgrade when the locale is upgraded.
Kind regards keld On Tue, Jun 18, 2002 at 10:28:40AM +0100, Markus Kuhn wrote: > Glenn Maynard wrote on 2002-06-18 04:31 UTC: > > I doubt Marcus would be interested in speed improvements if they're > > at the cost of the rest. > > I wrote the code first of all to specify the semantics of the function, > even though I don't think it does anything tremendously inefficent, and > I have not yet received a single profiling report that suggests that any > CPU on this planet spends a percentage of its time in this function that > would make it worthwhile to think about a serious optimization research > project. > > I'd rather not start any optimizing for speed without having written a > benchmark first, and I expect people who suggest improvements to do the > same. You can't optimize something without first being able to measure > the quantity you optimize. The actions of superscalar processors with > two layers of cache are far too difficult to understand to get > optimization right without measurement. > > If I needed a maximum-performance version of wcwidth, I would probabaly > try to unroll a binary decision tree as a nested structure of "if" > statements, base the split points on a sensible character-frequency > histogram (diffucult to agree upon, as this is obviously language > dependent), and interleave the comparisons and jumps to make maximum use > of however many integer pipelines are fashionable in the latest > generation of CPUs today. What I would actually code would be a Perl > program that generates the relevant C code from the Unicode tables. > > There are also obvious optimizations you can make for the implementation > of an mbswidth() function, which implements the comparisons without > actually doing any UTF-8 decoding. Again, if someone can document a > serious need by profiling, I'd be happy to have a look at playing with > that later this summer. But wcwidth is normally only called for text > that is displayed, and displaying is many orders of magnitude slower > than wcwidth, therefore I don't know a place where it could be worth > this effort. > > http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c > > Markus > > -- > Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK > Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> > > -- > Linux-UTF8: i18n of Linux on all levels > Archive: http://mail.nl.linux.org/linux-utf8/ -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
