From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA32442; Mon, 8 Dec 2003 21:51:58 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA00103 for ; Mon, 8 Dec 2003 21:51:57 +0100 (MET) Received: from mail2.tpgi.com.au (mail.tpgi.com.au [203.12.160.58]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id hB8Kpsr02740 for ; Mon, 8 Dec 2003 21:51:55 +0100 (MET) Received: from 203-213-83-56-syd-ts15-2600.tpgi.com.au (203-213-83-56-syd-ts15-2600.tpgi.com.au [203.213.83.56]) by mail2.tpgi.com.au (8.12.10/8.12.10) with ESMTP id hB8KpmbI022317; Tue, 9 Dec 2003 07:51:50 +1100 Subject: Re: [Caml-list] Object-oriented access bottleneck From: skaller Reply-To: skaller@ozemail.com.au To: Brian Hurt Cc: Nuutti Kotivuori , caml-list In-Reply-To: References: Content-Type: text/plain Message-Id: <1070913108.9189.30.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 09 Dec 2003 06:51:48 +1100 Content-Transfer-Encoding: 7bit X-TPG-Antivirus: Passed X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 bottleneck:01 ozemail:01 inlining:01 inlining:01 wrappers:01 pointers:01 subroutine:01 constructors:01 constructors:01 coding:03 classes:03 wrote:03 wrote:03 hmm:05 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 2003-12-08 at 06:30, Brian Hurt wrote: > On Sun, 7 Dec 2003, Nuutti Kotivuori wrote: > I actually question the value of inlining as a performance improvement, > unless it leads to other signifigant optimizations. Hmm. A block of n instructions containing a call to a block of m instructions is typically n + 1 + m + 1 instructions: at least a call and return are saved, even with no parameters. I guess your analysis might be right if a function is called more than once .. but for a single call, inlining surely must be better. In C++ there is no doubt that inlining is not just an optimisation but a mandatory feature: several classes of code, including wrappers (eg smart pointers) and of course constructors, require inlining or the coding style is useless. Of course, this is at a higher level than machine code subroutine inlining .. a lot more than just 2 instructions are saved (for example, default constructors are often NOPs ..) ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners