Re: [Caml-list] Execution time of class versus record

[Jon Harrop <jon@ffconsultancy.com>]

On Monday 25 June 2007 12:16:08 Arnaud Spiwack wrote:
> if I remember well,
> the arrays of floats are actually compiled a different way, using
> different get/set primitive,

Yes.

> there is still nothing at runtime 

Not quite: there is now run-time dispatch to the appropriate get/set primitive 
in polymorphic functions.

> ). So in 
> vew of this, the part of the coercion that'd be shift at run-time would
> be something rather rare (in the zoology of objects, object that deserve
> a specific run-time representation sound like a rather spare subset to
> me), an coincidental.

If these cases were rare, compiler writers would not bother optimizing them.

> > How can the current representation of records handle virtual method
> > dispatch?
>
> I'm not sure I will answer this question properly. But if we're talking
> of the same thing, virtual methods are not a runtime concern. You can't 
> create object of a virtual class anyway. It's a mere typing issue (and
> this time for very real, this does not fiddle with any concrete
> representation of any sort).
>
> I guess I haven't understand the question.

Run-time dispatch of virtual functions is the object oriented representation 
of sum types, so it can require run-time dispatch.

> > I think this choice makes OCaml's object system more orthogonal to the
> > rest of the language.
>
> Which specific choice are you refering to right now? (you lost me
> somewhere on the track).

Structurally sub-typed OOP complements the Hindley-Milner type system, IMHO.

> > and polymorphic variants.
>
> Indeed. For similar reason I reckon.
> I wonder how polymorphic variants are handled at compile time.

Like an ordinary variant with a single boxed argument but their ID is a hash 
of the string name of the constructor instead of an enumeration.

> They 
> probably get there label during linking I guess. I can't see how they'd
> work otherwise. (the OCaml manual states they are a pinch slower than
> non-polymorphic variants, could someone tell me what is the difference
> which makes that be?)

Polymorphic variant type constructors may have different numbers of arguments, 
so their representation is always boxed whereas multiple-argument variant 
types are unboxed.

For the same reason, there is a difference between:

  type t = A of int * int

and:

  type t = A of (int * int)

The former is unboxed and the latter is boxed (a reference to a pair). The 
boxing can degrade performance (it can also improve performance!).

Pattern matching is also less efficient for polymorphic variants. Look at the 
compiled bytecode, for example:

type x = A | B | C

let f = function
  | A -> 0
  | B -> 1
  | C -> 2

compiles to an efficient O(1) virtual table:

L1:     acc 0
        switch 5 4 3/
L5:     const 0
        return 1
L4:     const 1
        return 1
L3:     const 2
        return 1

but:

let g = function
  | `A -> 0
  | `B -> 1
  | `C -> 2

compiles to O(n) comparisons:

L1:     acc 0
        push
        const 66
        neqint
        branchifnot L3
        acc 0
        push
        const 67
        leint
        branchifnot L4
        const 2
        return 1
L4:     const 0
        return 1
L3:     const 1
        return 1

> > If I have two modules containing two classes and I want them to be
> > related, how can you implement that with structurally-subtyped OO if
> > method names are local to modules?
>
> Well, you could still use #OtherModule.m to call the other module's "m"
> method. And using "open OtherModule" as well. I must confess I'm not so
> sure it really makes a lot of sense to have these like that, but at
> least it'd be rather consistent.

I was referring to virtual function dispatch and not the explicit invocation 
of a particular member.

Consider this example:

module A = struct
  let foo = object method f n = n+1 end
end;;
module B = struct
  let bar = object method f n = n+2 end
end;;

let apply o = o#f;;

apply A.foo 0;;
apply B.bar 0;;

If modules imposed separate namespaces then the objects in the modules A and B 
could not be related, so you could not use them for dispatch in this way 
(probably a very common use of objects as well).

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?e