[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Is it woth to have SVN_REVNUM_T_FMT?

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-04-06 14:24:46 CEST

C.A.T.Magic wrote:

> Branko Čibej wrote:
>> That's the solution I like the least, because ut's not just a simple
>> search and replace -- at least not in the standard printf syntax -- and
>> it slows things down tremendously. On the other hand, none of the
>> printfs is in a performance-critial part of the code.
> how much does gettext impact the speed?
> does it use something like strcmp's (slow)
> or hashtables (average) inside, or does it replace
> the strings in the sourcecode with unique id's (fast)?

Gettext uses a string-to-string optimized hash table. When used with
GCC, it can take advantage of constant string keys by using a
pointer-based translation cache; that's one reason why you typically
don't want to parse the format strings before you hand them over to
gettext. You could do it afterwards, though.

So we have three options:

   1. Transform all paraneters to strings and use only %s in the format
      strings. This is the easiest short-term solution, and would also
      work for marshaling composite error messages from the server.
   2. Extend APR's formatter and use custom type-specific format codes.
      This looks like the cleanest solution for the long term, but would
      require an APR upgrade (and that also means we'd have to wait for
      the next httpd release)
   3. Use custom type-specific format codes but introduce a post-gettext
      parsing pass that would replace them with APR's #defines before
      they get to printf.

A combination of 3 and 2 woudl work, too -- do 3 first, then later fall
back to 2 if the available APR version supports it.

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 6 14:24:59 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.