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 TAA03249; Sun, 7 Dec 2003 19:14:37 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA02986 for ; Sun, 7 Dec 2003 19:14:36 +0100 (MET) Received: from smtp2.pp.htv.fi (smtp2.pp.htv.fi [213.243.153.14]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hB7IEZ121138 for ; Sun, 7 Dec 2003 19:14:35 +0100 (MET) Received: from posti.pp.htv.fi (posti.pp.htv.fi [212.90.64.50]) by smtp2.pp.htv.fi (Postfix) with ESMTP id 57890296C8C; Sun, 7 Dec 2003 20:14:35 +0200 (EET) Received: from oro (aka.pp.htv.fi [213.243.183.115]) by posti.pp.htv.fi (8.11.1 (Revision 1.5+JAGae91741+JAGae92668) /8.11.1) with ESMTP id hB7IEYT07245; Sun, 7 Dec 2003 20:14:34 +0200 (EET) Received: from naked by oro with local (Exim 3.36 #1 (Debian)) id 1AT3QP-0005a1-00; Sun, 07 Dec 2003 20:14:33 +0200 To: Brian Hurt Cc: caml-list@inria.fr Subject: Re: [Caml-list] Object-oriented access bottleneck References: From: Nuutti Kotivuori Date: Sun, 07 Dec 2003 20:14:33 +0200 In-Reply-To: (Brian Hurt's message of "Sun, 7 Dec 2003 12:23:20 -0600 (CST)") Message-ID: <87n0a4cx6e.fsf@naked.iki.fi> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 bottleneck:01 foo:01 foo:01 inlining:01 caml:01 int:01 underlying:01 o'caml:02 classes:03 wrote:03 optimizing:03 object:03 let:04 define:05 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Brian Hurt wrote: > I don't think there can be. Consider the function: > > let f c = c#foo 3 ;; > > In O'caml, this has type: < foo : int -> 'a; .. > -> 'a which > basically means it accepts any object with a foo member function. > > So what happens if we define two classes, which don't relate to each > other except each has a foo member function. Only in one class foo > is a virtual function, and in the second class foo is a non-virtual Yes, I mentioned this in the mail (in the part that was snipped). It does not work for the general case - however if we do know the exact type, it could be done. > A better alternative would be, I think, to spend a little time > optimizing virtual function calls, so that they are faster. Well sure, that will help and is a good idea in general. But it will never allow for inlining of the function body into the calling function, and as such will never solve the underlying problem. -- Naked ------------------- 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