Firefox performance

[Callum Lerwick]

On Sun, 2009-02-15 at 01:36 -0500, Gregory Maxwell wrote:
> Sadly, the profiles are fairly tied to the source code.
> (This is the same data that gcov uses, so you can look at the gcov manpage
> for more information)
> 
> GCC complains loudly if they don't match exactly, and any line number offset
> will scramble the profiling and likely give  worse performance than  without
> profile driven optimization at all. This is quite unfortunate because I like
> the idea of distributing  the profile along with the source since that means
> the compilation would be more easily reproducible.
> 
> (and keeping profile generation out of the build system is probably a
>  precondition for this kind of thing ever seeing widespread use)

I think a better option is to just borrow a trick from the Linux kernel:

http://kerneltrap.org/node/4705

Just putting the optimization hints directly in the source solves all
these problems. I've done this in an upcoming OpenJPEG patch:

/*
A convention borrowed from the Linux kernel.
Provides gcc with branch optimization hints.
*/
#ifdef __GNUC__
	#define likely(x)   __builtin_expect(!!(x), 1)
	#define unlikely(x) __builtin_expect(!!(x), 0)
#else
	#define likely(x)   (x)
	#define unlikely(x) (x)
#endif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090217/5e2300e8/attachment.bin