Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

[Matt Mackall <mpm@selenic.com>]

On Thu, Jan 05, 2006 at 11:40:08AM -0800, Linus Torvalds wrote:
> 
> 
> On Thu, 5 Jan 2006, Linus Torvalds wrote:
> > 
> > That way the "profile data" actually follows the source code, and is thus 
> > actually relevant to an open-source project. Because we do _not_ start 
> > having specially optimized binaries. That's against the whole point of 
> > being open source and trying to get users to get more deeply involved with 
> > the project.
> 
> Btw, having annotations obviously works, although it equally obviously 
> will limit the scope of this kind of profile data. You won't get the same 
> kind of granularity, and you'd only do the annotations for cases that end 
> up being very clear-cut. But having an automated feedback cycle for adding 
> (and removing!) annotations should make it pretty maintainable in the long 
> run, although the initial annotations migh only end up being for really 
> core code.
> 
> There's a few papers around that claim that programmers are often very 
> wrong when they estimate probabilities for different code-paths, and that 
> you absolutely need automation to get it right. I believe them. But the 
> fact that you need automation doesn't automatically mean that you should 
> feed the compiler a profile-data-blob.

I think it's a mistake to interleave this data into the C source. It's
expensive and tedious to change relative to its volatility. What I was
proposing was something like, say, arch/i386/popularity.lst, which
would simply contain a list of the most popular n% of functions sorted
by popularity. As text, of course.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/