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 DAA11942; Sun, 7 Dec 2003 03:39:16 +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 DAA08702 for ; Sun, 7 Dec 2003 03:39:14 +0100 (MET) Received: from smtp3.pp.htv.fi (smtp3.pp.htv.fi [213.243.153.173]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hB72dE109204 for ; Sun, 7 Dec 2003 03:39:14 +0100 (MET) Received: from posti.pp.htv.fi (posti.pp.htv.fi [212.90.64.50]) by smtp3.pp.htv.fi (Postfix) with ESMTP id EBCCC27BB59 for ; Sun, 7 Dec 2003 04:39:13 +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 hB72dDT00636 for ; Sun, 7 Dec 2003 04:39:13 +0200 (EET) Received: from naked by oro with local (Exim 3.36 #1 (Debian)) id 1ASopF-0005D4-00 for ; Sun, 07 Dec 2003 04:39:13 +0200 To: caml-list@inria.fr Subject: [Caml-list] Object-oriented access bottleneck From: Nuutti Kotivuori Date: Sun, 07 Dec 2003 04:39:12 +0200 Message-ID: <871xrhe4hb.fsf@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; bottleneck:01 bottleneck:01 derives:01 subtyping:01 lessened:01 hackery:01 circumvent:01 inlined:01 compiler:01 compiler:01 ocaml:01 ocaml:01 caml:01 coercion:01 declaring:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk This message identical to the post I made to comp.lang.ml a while back - but I think it will have a better audience over here, now that I decided to join the list. --- Lately I've been having a bit of a dilemma caused by a bottleneck from object-oriented access in Ocaml. The problem derives from the implementation of method calls through lazy binding. Compiled languages which offer an object oriented system usually provide a way for methods to short-circuit the lazy binding (or virtual function table) system. In C++, non-virtual functions do this, in Java, declaring a method final gives the compiler a hint about this. In this case, the compiler can inline the method into the caller. Ocaml doesn't seem to be provide such a way. Upon closer inspection it is obvious how this is so - if we allow subtyping by coercion, we have no idea of the underlying implementation of the object given to the function - where as when inheritance relationships are traditionally forced in languages, we know that the implementation is composed of the class atleast. So, the obvious solution is to write the functions that do not need the lazy binding outside the class itself, as normal functions. But that doesn't help either - because there's no way to access data in the object without going through a lazy binding call again. What this all amounts to is that you cannot store data inside classes at all, if some parts of it might require performance critical work. The problem can be lessened by placing the data in a record, which is only referenced from the object and passed around - or something similar - but that adds complexity into the whole thing. And theoretically if you absolutely *know* what type your object is and that it isn't subtyped, you could use the direct field accesses in Obj, but that amounts to major hackery already. So - I am asking if I'm correct in my deductions here, or if I missed some important point. Or if there's an alternative way to circumvent this restriction. To summarize - is there any way to have some function (or method or whatever) that is able to access object member data, without the overhead of a lazy binding function call? Preferably ofcourse such a function should be eligible to be inlined. Thanks in advance, -- 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