Version française
Home     About     Download     Resources     Contact us    
Browse thread
Execution time of class versus record
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Arnaud Spiwack <aspiwack@l...>
Subject: Re: [Caml-list] Execution time of class versus record
Well, this was quite a misunderstanding of my question.

Obviously objects are not records. But the essential difference seems to 
be more at type level (btw object coercion should never cost anything 
since they are merely type level tools).

At runtime, I can't see anything to preven objects to be exactly records 
(with a bit of care taken during compilation for method names). John 
Skaller's answer is not really convincing either, since the type of a 
value does not change the size of the value, having the same name 
associated to different types does not seem to me a good motivation.

I was referring earlier to Xavier Leroy's technical report, I can't 
remember precisely what the principle was, but there was some sort of 
label compilation for records with shared names. I tend to remember that 
it used a sparse encoding of records (with holes corresponding to the 
missing labels), thus it might have been a problem, but I believe the 
representation was rather dense in case of only-unique-name-based 
record. Another lead is maybe something due to module compilation, the 
earlier idea might imply that each module has it's own namespace (it's 
the case for almost everything in OCaml, except, if I'm not mistaking, 
method names). If it is the motivation for having a runtime 
representation of objects different to that of records, the question 
that raises nex is: what is the motivation for not having 
module-specific namespaces for method names?


Arnaud Spiwack

Gerd Stolpmann a écrit :
> Am Sonntag, den 24.06.2007, 18:06 +0200 schrieb Arnaud Spiwack:
>   
>> Which obviously raises the question: What is the motivation for the 
>> object to be encoded differently than records? 
>>     
>
> Objects support subtyping whereas records do not. And coercion costs
> nothing, thanks to the object representation.
>
> E.g.
>
> let print_m2 obj = print_string obj#m2
>
> let x1 = object method m2 = "x1" method m3 = 42 end
>
> let x2 = object method m1 = 98 method m2 = "x2" end
>
> print_m2 x1
> print_m2 x2
>
> See that in x1 the called method m2 is the first in the list, and in x2
> it is the second? In a record the order of the components in the memory
> layout is the same as the order in the type. If we did that the same
> with objects, we would have to do rearrangements when we coerce objects
> to supertypes (which happens here when print_m2 is called).
>
> Note also that object types are structural and not nominal as for many
> object-oriented languages (i.e. you don't have to declare that x1 and x2
> will be used as subtypes of <m2:string>).
>
>   
>> I remember reading in 
>> Xavier Leroy's technical report about the first ZAM how he prepared the 
>> field for extensible records (to be able to implement objects). There 
>> the name of the fields were compiled into an adress, resulting no 
>> runtime conversion.
>>
>> I can imagine a couple of applications to the current situation (though 
>> I'm not so sure they would work), but I'm really interested in the 
>> original reason of this design choice.
>>
>>
>> Arnaud Spiwack
>>
>>
>>
>> Till Varoquaux a écrit :
>>     
>>> Objects in OCaml are dictionary based, which means methods names must
>>> be looked up in a table in order to get there addresses. Record fields
>>> on the other hand are addressed directly. Take two files test.ml and
>>> test2.ml:
>>> test.ml:
>>> type b=
>>> {
>>> field:int
>>> }
>>> let a={field=1};;
>>> print_int a.field
>>>
>>> test2.ml
>>> let a=object
>>> method field=1
>>> end;;
>>> print_int a#field
>>>
>>> and dump there intermediate representation (-dlambda)
>>>
>>> test.ml
>>>
>>> (setglobal Test!
>>>  (let (a/61 [0: 1])
>>>    (seq (apply (field 27 (global Pervasives!)) (field 0 a/61))
>>>      (makeblock 0 a/61))))
>>>
>>> test2.ml
>>>
>>> (setglobal Test2!
>>>  (let
>>>    (a/58
>>>       (let
>>>         (class/72 (apply (field 15 (global CamlinternalOO!)) [0: 
>>> #"field"])
>>>          obj_init/80
>>>            (let
>>>              (field/61
>>>                 (apply (field 6 (global CamlinternalOO!)) class/72 
>>> #"field"))
>>>              (seq
>>>                (apply (field 10 (global CamlinternalOO!)) class/72
>>>                  (makeblock 0 field/61 0a 1))
>>>                (function env/74
>>>                  (apply (field 23 (global CamlinternalOO!)) 0a 
>>> class/72)))))
>>>         (seq (apply (field 16 (global CamlinternalOO!)) class/72)
>>>           (apply obj_init/80 0a))))
>>>    (seq (apply (field 27 (global Pervasives!)) (send a/58 9671866))
>>>      (makeblock 0 a/58))))
>>>
>>> You can now understand where the performance issues comes from.
>>>
>>> Cheers,
>>> Till
>>> On 6/24/07, Jon Harrop <jon@ffconsultancy.com> wrote:
>>>       
>>>> On Sunday 24 June 2007 16:14:54 tmp123@menta.net wrote:
>>>>         
>>>>> Hello,
>>>>>
>>>>> I've tried to implement two equivalent small programs, the one using
>>>>> class, the other one using records. The resulting execution times says
>>>>> that class are 7-8 times slower than record (compiled with ocamlopt 
>>>>>           
>>>> in a
>>>>         
>>>>> Intel machine).
>>>>>
>>>>> Please, knows someone what I'm doing wrong?
>>>>>           
>>>> You aren't doing anything wrong.
>>>>
>>>> -- 
>>>> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
>>>> The OCaml Journal
>>>> http://www.ffconsultancy.com/products/ocaml_journal/?e
>>>>
>>>> _______________________________________________
>>>> Caml-list mailing list. Subscription management:
>>>> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>>>> Archives: http://caml.inria.fr
>>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>>>
>>>>         
>>>       
>> _______________________________________________
>> Caml-list mailing list. Subscription management:
>> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>> Archives: http://caml.inria.fr
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>>