From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 76952BC69 for ; Sun, 24 Jun 2007 20:19:01 +0200 (CEST) Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net [203.16.214.135]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5OIIxj6022080 for ; Sun, 24 Jun 2007 20:19:00 +0200 X-IronPort-AV: E=Sophos;i="4.16,456,1175437800"; d="scan'208";a="107035897" Received: from ppp59-167-2-129.lns1.syd7.internode.on.net (HELO [192.168.1.201]) ([59.167.2.129]) by ipmail03.adl2.internode.on.net with ESMTP; 25 Jun 2007 03:48:57 +0930 Subject: Re: [Caml-list] Execution time of class versus record From: skaller To: Arnaud Spiwack Cc: caml-list@yquem.inria.fr In-Reply-To: <467E9676.50905@lix.polytechnique.fr> References: <467E8A6E.9050700@menta.net> <200706241629.50551.jon@ffconsultancy.com> <9d3ec8300706240848o6ac94a29q67f32d4774c88e0e@mail.gmail.com> <467E9676.50905@lix.polytechnique.fr> Content-Type: text/plain Date: Mon, 25 Jun 2007 04:18:55 +1000 Message-Id: <1182709135.6233.13.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 467EB593.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0200,:01 ocaml:01 indirection:01 supertype:01 supertype:01 statically:01 subtype:01 subtype:01 statically:01 compiler:01 sourceforge:01 wrote:01 arnaud:01 dynamically:01 slower:01 On Sun, 2007-06-24 at 18:06 +0200, Arnaud Spiwack wrote: > Which obviously raises the question: What is the motivation for the > object to be encoded differently than records? Someone with more expertise will assuredly correct me, but this is my picture: Ocaml objects can be accessed via a class type. An object matches a type if it has the required methods, matched by name and type (structural typing). For a given class type, objects of different types might match, so there has to be a lookup table mapping the method of the call to the method of the object. Therefore, the indirection is unavoidable. But why can't we use an array, indexed by the method number? This would be possible. However consider a coercion from a class type to a supertype: the supertype might have less methods, or methods in a different order. So the coercion would require dynamically building a new method array. On the other hand with a dictionary, the method lookup is slower, but the same dictionary can be used for the supertype, since statically, you can only lookup a method that is sure to be in the subtype .. the other methods of the subtype simply won't be found. The dictionary of an object is known statically at construction time so it can be created once on program initialisation. This means: construction and coercion are fast, the dictionary is already built. Lookup is slower than optimal. And finally, the dictionary method is easier for the compiler writers: just store the dictionary in the object. -- John Skaller Felix, successor to C++: http://felix.sf.net