caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: naked+caml@naked.iki.fi
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Object-oriented access bottleneck
Date: Sun, 07 Dec 2003 19:27:02 +0900	[thread overview]
Message-ID: <20031207192702D.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <871xrhe4hb.fsf@iki.fi>

From: Nuutti Kotivuori <naked+caml@naked.iki.fi>

[...]
> What this all amounts to is that you cannot store data inside classes
> at all, if some parts of it might require performance critical
> work. The problem can be lessened by placing the data in a record,
> which is only referenced from the object and passed around - or
> something similar - but that adds complexity into the whole thing.
> 
> So - I am asking if I'm correct in my deductions here, or if I missed
> some important point. Or if there's an alternative way to circumvent
> this restriction.
> 
> To summarize - is there any way to have some function (or method or
> whatever) that is able to access object member data, without the
> overhead of a lazy binding function call? Preferably ofcourse such a
> function should be eligible to be inlined.

I think the correct name is "late binding".
But you're correct. Classes are not very good for performance, and
nothing serious is done for their optimization.

As you remarked already, the object model chosen in ocaml makes final
methods mostly irrelevant. There is however one way to tell the
compiler that a specific method code should be used, but this only
works for calls inside a class:
   inherit c ... as super
   method p = ... super#m ...
In this case, if we know statically the class c, we exactly know the
code referenced by super#m. However, this information is not used
currently (and is probably not what you want for your own code). And
there is no way to tell this for a method defined in the same class.

The approach you suggest of using a record sounds like a good idea.
This will make the problem clearer: either you really need objects,
and external functions are just there for performance; or you didn't
need them anyway, and you will be able to rewrite everything as
functions with a record parameter.
Note also that this is not as clumsy as it looks: even without records,
you can already pass (by hand) all non-mutable fields to external
functions (labelled parameters handy there?)

If your problem requires objects, I'm interested if you can show me
some code: I'm in the process of making extensive changes to object
compilation, and I need serious performance sensitive benchmarks.
(All my programs using objects call them only a few times, so that
method calls could be 10 times slower and I wouldn't care)

Regards,

Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  parent reply	other threads:[~2003-12-07 10:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-07  2:39 Nuutti Kotivuori
2003-12-07  2:59 ` Nicolas Cannasse
2003-12-07 11:22   ` Benjamin Geer
2003-12-07 14:12     ` Nicolas Cannasse
2003-12-07 18:04   ` Nuutti Kotivuori
2003-12-07 10:27 ` Jacques Garrigue [this message]
2003-12-07 19:46   ` Nuutti Kotivuori
2003-12-08  1:07     ` Jacques Garrigue
2003-12-08 15:08       ` Nuutti Kotivuori
2003-12-08 15:42         ` Richard Jones
2003-12-09  0:26           ` Nicolas Cannasse
2003-12-09 12:10             ` Nuutti Kotivuori
2003-12-09 13:17               ` Olivier Andrieu
2003-12-09 13:53                 ` Nuutti Kotivuori
2003-12-08 17:51       ` Brian Hurt
2003-12-08 18:19         ` brogoff
2003-12-08 20:09           ` Brian Hurt
2003-12-08 19:02         ` Xavier Leroy
2003-12-08 21:37           ` Brian Hurt
2003-12-08 21:06             ` Nuutti Kotivuori
2003-12-08 22:30             ` malc
2003-12-07 18:23 ` Brian Hurt
2003-12-07 18:14   ` Nuutti Kotivuori
2003-12-07 19:30     ` Brian Hurt
2003-12-07 23:50       ` Abdulaziz Ghuloum
2003-12-08 17:29         ` Brian Hurt
2003-12-08 18:48           ` Nuutti Kotivuori
2003-12-08 10:17       ` Nuutti Kotivuori
2003-12-08 19:51       ` skaller

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=20031207192702D.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=naked+caml@naked.iki.fi \
    /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).