From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24653 invoked by alias); 30 Jul 2003 16:09:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 24641 invoked from network); 30 Jul 2003 16:09:45 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 30 Jul 2003 16:09:45 -0000 Received: by nile.gnat.com (Postfix, from userid 338) id 5C81AF2E03; Wed, 30 Jul 2003 12:09:45 -0400 (EDT) To: Richard.Earnshaw@arm.com, coyote@coyotegulch.com Subject: Re: std::pow implementation Cc: aoliva@redhat.com, gcc@gcc.gnu.org, gdr@integrable-solutions.net, kgardas@objectsecurity.com, rguenth@tat.physik.uni-tuebingen.de Message-Id: <20030730160945.5C81AF2E03@nile.gnat.com> Date: Wed, 30 Jul 2003 16:36:00 -0000 From: dewar@gnat.com (Robert Dewar) X-SW-Source: 2003-07/txt/msg02212.txt.bz2 > Inlining is an optimization; in all but the most obvious and trivial > cases (e.g., simple assignments), it should be performed by a programmer > *after* profiling, and not before. "Premature optimization is the root > of all evil", according to Hoare and Knuth; in code reviews, I tend to > grumble about people who insist on inlining and using cute tricks, when > they haven't done any analysis as to how their choices affect code > quality and performance. I strongly disagree with this. Profiling is simply not an effective way of identifying functions that benefit from inlining. Profiling is a very crude tool that is helpful in eliminating hot spots but that's all. The reason for not taking this view of inlining is that unless you get in the mindset that inlining will be done routinely by the compiler (at your direction) then you will tend to shy away from the use of trivial abstraction functions because you will worry about efficiency. The quote about premature optimization here is wrong I think. What Knuth was talking about (go back and look at what he really said, not just the sound bite) was distorting the code prematurely and unnecessarily in the interests of optimization. In fact, the liberal use of inline tends to *prevent* premature optimization (of the kind I mentioned above, avoidance of abstraction), and certainly does not distort the code.