[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH/RFC 0/5] Add internationalization support to Git
From:       Ævar Arnfjörð Bjarmason <avarab () gmail ! com>
Date:       2010-05-31 12:17:11
Message-ID: AANLkTinDqGaqlTJs91vB8giQGo6GfEmCdX3wpNX7lMCR () mail ! gmail ! com
[Download RAW message or body]

On Sun, May 30, 2010 at 22:23, Jonathan Nieder <jrnieder@gmail.com> wrote:
> [...]
> It would seem that __attribute__((__pure__)) should let the compiler give
> us the best of both worlds, but no luck.  Even __attribute__((__const__))
> is ignored; the compiler inlines the body of _() before it has a chance
> to notice.
>
> We can fool the compiler into paying attention by making it not
> inlinable: if gettext.h contains
>
> | extern char *_(const char *s) __attribute__((__format_arg__(1), __const__));
>
> and a separate gettext.c contains
>
> | #include <libintl.h>
> | #include "gettext.h"
> | char *_(const char *s) { return gettext(s); }
>
> we get the performance of B again:
>
>  1.36user 0.01system 0:01.38elapsed 98%CPU (0avgtext+0avgdata 2304maxresident)k
>  0inputs+0outputs (0major+180minor)pagefaults 0swaps
>
> This amounts to lying to the compiler, since it is possible for the string
> pointed to by a single address s to differ between calls to _.  The __pure__
> attribute would be more honest, but for reasons I don’t understand it
> suppresses the optimization.
>
> Moral of the story: at least in simple cases, we can keep the performance
> and the typechecking.  Phew.

Awesome, how portable is this? If it's just GCC I guess it can just be
wrapped in #ifdef __GNUC__.

Thanks for investingating this.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]