caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Bardur Arantsson <spam@scientician.net>
To: caml-list@inria.fr
Subject: Re: announce: callbacks-0.1
Date: Fri, 09 Sep 2005 08:30:05 +0200	[thread overview]
Message-ID: <dfra5e$nlc$1@sea.gmane.org> (raw)
In-Reply-To: <dfqhl4$tk6$1@sea.gmane.org>

On Fri, Sep 09, 2005 at 07:53:17AM +0200, Christophe Raffalli wrote:

>> Now, I'll freely admit that I haven't tested it specifically, but I
>>  suspect performance will be worse when using register_global_root
>>  to register callback closures instead of just using a mapping from
>>  "int" (or whatever type your callback identifier would be on the C
>>  side) to closures "stored" on the OCaml side. There was a post on
>>  this list not too long ago which exposed efficiency issues with 
>> register_global_root when registering lots and lots of roots.

> anyway, there should not be that many callbacks ?

That depends hugely on what kind of library you're wrapping. I did a
wrapper for libevent (events on file descriptors and other similar stuff
like alarms, etc.) and what ended up happening was that a 1) lot of the
time a relatively large amount of callbacks were registered, orm 2)
callbacks would be registered/unregistered a lot. I did try using
*_global_roots in my libevent wrapper, but the performance was awful
until I changed it to use an (fd->callback) hashtable on the OCaml side.

(In the case of file descriptors or similar objects you can try to be
more clever and just use an array of callbacks and use the file
descriptor as the index; I didn't bother with this in my wrapper library
since the performance was OK as it was).

> Moreover, I suspect (but may be wrong) that register_global_root () 
> is or could be optimized for closure on closed functions, and this 
> will be the case of most closure with my approach.

 From the implementation in globroots.c it would seem that
register_global_root is at least O(n) in the number of roots, and that
it has a large constant overhead compared to e.g. adding something to a
hashtable. So it may not be the fact that a closure may keep things
alive that's slowing it down, but rather just a slow implementation of 
register_global_root itself.

[--snip--]

-- 
Bardur Arantsson
<bardur@imada.sdu.dk>
<bardur@scientician.net>

- There are a thousand forms of subversion, all of them
interesting. But few, in my opinion, can equal the convenience
and immediacy of the cream pie.
                                                        Noël Godin


  reply	other threads:[~2005-09-09  6:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-08 16:31 Christophe Raffalli
     [not found] ` <4320A68E.1060608@xs4all.nl>
2005-09-08 21:24   ` [Caml-list] " Christophe Raffalli
2005-09-08 23:31     ` Bardur Arantsson
2005-09-09  6:30       ` Bardur Arantsson [this message]
2005-09-10  7:04         ` [Caml-list] " Xavier Leroy
2005-09-10  7:31           ` Bardur Arantsson
2005-09-10 13:04           ` [Caml-list] " Yaron Minsky
2005-09-10 21:02           ` caml_register_unmutable_global_root Christophe Raffalli

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='dfra5e$nlc$1@sea.gmane.org' \
    --to=spam@scientician.net \
    --cc=caml-list@inria.fr \
    /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).