[Caml-list] Just how slow are classes?

[Caml-list] Just how slow are classes?

[Jordan W]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

I am aware of some of the reasons why OCaml classes and objects are slower
than records. The lack of nominal subtyping makes determining memory layout
at compile time much more difficult.

While I am also curious why "nice cases" of objects/classes couldn't be
optimized (perhaps some link time check), when most of the objects adhere
to a nice hierarchy, I would like to defer that discussion until another
time. For now, my primary question is: Just *how* slow are objects/classes?
Has there been any relevant benchmarking efforts that could shed some light
on this?

For example, how much more expensive in terms of memory are objects
(compared to records). How much slower are property accesses and method
invocations than record accesses and module function invocations?

Jordan

[-- Attachment #2: Type: text/html, Size: 892 bytes --]

Re: [Caml-list] Just how slow are classes?

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]

Am Freitag, den 18.12.2015, 00:19 -0800 schrieb Jordan W:
> I am aware of some of the reasons why OCaml classes and objects are
> slower than records. The lack of nominal subtyping makes determining
> memory layout at compile time much more difficult.
> 
> 
> While I am also curious why "nice cases" of objects/classes couldn't
> be optimized (perhaps some link time check), when most of the objects
> adhere to a nice hierarchy, I would like to defer that discussion
> until another time.

Oh, this is quickly explained. There is no hierarchy at runtime you can
exploit. Remember that object X can be a subtype of object Y even if
there is no inheritance relationship. This is very different from other
OO languages.

>  For now, my primary question is: Just *how* slow are objects/classes?
> Has there been any relevant benchmarking efforts that could shed some
> light on this?

It is essentially an additional hash table lookup.

> For example, how much more expensive in terms of memory are objects
> (compared to records). How much slower are property accesses and
> method invocations than record accesses and module function
> invocations?

It is hard to give a number because function invocations can be cheap
but also quite expensive when there are lots of arguments and many
register spills. It also depends on whether you always call the same
function or whether it changes every time (at the same point in the
program, i.e. per generated indirect jump).

Note that you can factor out the additional lookup when there are method
arguments, e.g. if you have

method foo : s -> t

you can do this:

let f = obj#foo

and then later, e.g. in a loop

f arg

which is then only the function call, w/o method lookup. This doesn't
work, though, when there are no method arguments.

Gerd

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Caml-list] Just how slow are classes?

[David Rajchenbach-Teller]

On 18/12/15 12:06, Gerd Stolpmann wrote:
> Oh, this is quickly explained. There is no hierarchy at runtime you can
> exploit. Remember that object X can be a subtype of object Y even if
> there is no inheritance relationship. This is very different from other
> OO languages.

As a side-note, JS JIT engines manage rather well in most common cases,
despite the absence of inheritance. If my memory serves, JIT engines
manage to compile simple lookups to essentially a simple array access
(there's also need to check a tag, I don't remember if the tag is in a
fat pointer or if it needs a dereference).

> 
>>  For now, my primary question is: Just *how* slow are objects/classes?
>> Has there been any relevant benchmarking efforts that could shed some
>> light on this?
> 
> It is essentially an additional hash table lookup.

I thought that the OCaml compiler implemented inline caching in most
common cases?

Cheers,
 David

Re: [Caml-list] Just how slow are classes?

[Leo White]

> > While I am also curious why "nice cases" of objects/classes couldn't
> > be optimized (perhaps some link time check), when most of the objects
> > adhere to a nice hierarchy, I would like to defer that discussion
> > until another time.
> 
> Oh, this is quickly explained. There is no hierarchy at runtime you can
> exploit. Remember that object X can be a subtype of object Y even if
> there is no inheritance relationship. This is very different from other
> OO languages.
> 

It is worth noting that you get similar issues with things like Java interfaces
(you can think of every method in an OCaml object type as a Java interface
containing a single method), and there are some effective mechanisms for
optimising them. The most important of these is inline method caching, which
is implemented for OCaml objects. Others, such as perfect hashing[1] are not
implemented for OCaml, so there is probably room for improvement, but they
would require significant amounts of work.

Regards,

Leo

[1] http://www.lirmm.fr/~ducour/Publis/RD-TOPLAS-08.pdf