caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Jordan W <jordojw@gmail.com>
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Just how slow are classes?
Date: Fri, 18 Dec 2015 12:06:57 +0100	[thread overview]
Message-ID: <1450436817.23408.54.camel@e130.lan.sumadev.de> (raw)
In-Reply-To: <CAPOA5_6cY1EQTYWJb6wMqJqBJsfLm9zgtfESrUBEZ1VtkCWmAg@mail.gmail.com>

[-- 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 --]

  reply	other threads:[~2015-12-18 11:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-18  8:19 Jordan W
2015-12-18 11:06 ` Gerd Stolpmann [this message]
2015-12-18 11:13   ` David Rajchenbach-Teller
2015-12-18 11:19   ` Leo White

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1450436817.23408.54.camel@e130.lan.sumadev.de \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@inria.fr \
    --cc=jordojw@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).