[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: inline build_string performance

From: Dmitry Antipov
Subject: Re: inline build_string performance
Date: Tue, 26 Jun 2012 21:58:34 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1

On 06/26/2012 09:37 PM, Paul Eggert wrote:

Sure, but if we we use build_literal for literals, and
build_string for non-literals, there's a performance
downside for having build_string be inline (namely,
it bloats the code), but no performance upside.

I don't understand this - build_string is a macro which expands to
build_literal (S, strlen (S)) if S is a compile-time constant,
and to make_string (S, strlen (S)) otherwise.  Note that it's possible
to have a nasty bug if someone calls build_literal with non-ASCII
string constant - it's definitely impossible to determine whether
a string constant is non-ASCII at compile time.

Perhaps I'm not quite following your idea, as
I thought the signature would be build_literal ("foo"),
whereas your build_literal also wants the string length.

This assumes something like:

#define build_literal(str) __build_literal (str, strlen (str))

and clever compiler which can optimize away calls to strlen
if STR is a compile-time constant.

Another approach is to refactor all code like:

x = build_string ("test");


x = build_literal ("test", 4);

This tends to be more error-prone in cases of size mismatch. But
it should be easy to implement a debugging version to use with
--enable-checking configure option; and there will be no dependency
from the compiler.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]