Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140728162731.GD1674@brightrain.aerifal.cx>
Date: Mon, 28 Jul 2014 12:27:32 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Non-stub gettext API functions committed, ready for
 testing

On Mon, Jul 28, 2014 at 04:01:52PM +0200, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@...t70.net> [2014-07-28 15:00:17 +0200]:
> > * Szabolcs Nagy <nsz@...t70.net> [2014-07-28 12:18:30 +0200]:
> > > the parser and eval code is about 2k now, i can try to do it
> > > without a separate parsing step (my approach requires a 100-200
> > > byte buffer to store the parsed expr now)
> > > 
> > 
> > attached a simpler solution without separate parsing
> > (code is about 1.4k now, and it is more compatible
> > with gnu gettext)
> > 
> 
> using a complex plural expression (arabic):
> 
> "(n==0 ? 0 : n==1 ? 1 : n==2 ? 2 : n%100>=3 && n%100<=10 ? 3 : n%100>=11 ? 4 : 5);"
> 
> the runtime of my preparsed vs interpreted implementation is
> 0.1-0.5us vs 3us testing on a few small n.

My leaning is to go with the version that's smaller and more flexible;
I think the time spent in this function will usually be heavily
dominated by the binary search for the message text. But it's cool to
have both for possible future uses (independent of musl, even).

BTW one way to reduce the cost is to skip the whole plural computation
when msgid1==msgid2 (as pointers). This is always true when dcngettext
is called by one of the "non-n" gettext functions.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.