From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id D46D7BDCB for ; Fri, 9 Sep 2005 08:33:13 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j896XDxe022409 for ; Fri, 9 Sep 2005 08:33:13 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id IAA18553 for ; Fri, 9 Sep 2005 08:33:12 +0200 (MET DST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j896XBw9017670 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 9 Sep 2005 08:33:12 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EDcPr-00009V-0A for caml-list@inria.fr; Fri, 09 Sep 2005 08:31:15 +0200 Received: from 0x50a5bb8d.odnxx9.adsl-dhcp.tele.dk ([80.165.187.141]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2005 08:31:14 +0200 Received: from spam by 0x50a5bb8d.odnxx9.adsl-dhcp.tele.dk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2005 08:31:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Bardur Arantsson Subject: Re: announce: callbacks-0.1 Date: Fri, 09 Sep 2005 08:30:05 +0200 Message-ID: References: <43206744.5090907@univ-savoie.fr> <4320A68E.1060608@xs4all.nl> <4320ABF7.7020009@univ-savoie.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 0x50a5bb8d.odnxx9.adsl-dhcp.tele.dk User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050803) X-Accept-Language: en-us, en In-Reply-To: Sender: news X-Miltered: at nez-perce with ID 43212CA9.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 43212CA7.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; christophe:01 raffalli:01 ocaml:01 callbacks:01 descriptors:01 callbacks:01 hashtable:01 ocaml:01 descriptors:01 globroots:01 hashtable:01 sdu:01 unregistered:98 wrote:01 closures:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 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 - 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