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 LAA22010; Sun, 7 Dec 2003 11:26:19 +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 LAA22512 for ; Sun, 7 Dec 2003 11:26:17 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id hB7AQFr04952 for ; Sun, 7 Dec 2003 11:26:16 +0100 (MET) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2-20030924/3.7W) with ESMTP id TAA07117; Sun, 7 Dec 2003 19:26:09 +0900 (JST) To: naked+caml@naked.iki.fi Cc: caml-list@inria.fr Subject: Re: [Caml-list] Object-oriented access bottleneck In-Reply-To: <871xrhe4hb.fsf@iki.fi> References: <871xrhe4hb.fsf@iki.fi> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20031207192702D.garrigue@kurims.kyoto-u.ac.jp> Date: Sun, 07 Dec 2003 19:27:02 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 bottleneck:01 jacques:01 lessened:01 circumvent:01 inlined:01 model:01 statically:01 clumsy:01 non-mutable:01 slower:01 jacques:01 compiler:01 ocaml:01 caml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Nuutti Kotivuori [...] > 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. > > 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. I think the correct name is "late binding". But you're correct. Classes are not very good for performance, and nothing serious is done for their optimization. As you remarked already, the object model chosen in ocaml makes final methods mostly irrelevant. There is however one way to tell the compiler that a specific method code should be used, but this only works for calls inside a class: inherit c ... as super method p = ... super#m ... In this case, if we know statically the class c, we exactly know the code referenced by super#m. However, this information is not used currently (and is probably not what you want for your own code). And there is no way to tell this for a method defined in the same class. The approach you suggest of using a record sounds like a good idea. This will make the problem clearer: either you really need objects, and external functions are just there for performance; or you didn't need them anyway, and you will be able to rewrite everything as functions with a record parameter. Note also that this is not as clumsy as it looks: even without records, you can already pass (by hand) all non-mutable fields to external functions (labelled parameters handy there?) If your problem requires objects, I'm interested if you can show me some code: I'm in the process of making extensive changes to object compilation, and I need serious performance sensitive benchmarks. (All my programs using objects call them only a few times, so that method calls could be 10 times slower and I wouldn't care) Regards, Jacques Garrigue ------------------- 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