From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q3JAvpkl013287 for ; Thu, 19 Apr 2012 12:57:51 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEDAJ/uj09KN1ZKnGdsb2JhbABDhWWrfAEBAQEBCAsJHSeCCQEBBAEjVgULCQIaAhgOAgI9ChAGG4gCBQSnQpMsgS+NdjVjBJtQjUM X-IronPort-AV: E=Sophos;i="4.75,445,1330902000"; d="scan'208";a="154709964" Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74]) by mail1-smtp-roc.national.inria.fr with ESMTP; 19 Apr 2012 12:57:45 +0200 Received: from heyho.local (53-232.197-178.cust.bluewin.ch [178.197.232.53]) by smtp.webfaction.com (Postfix) with ESMTP id 97D9D26EED07; Thu, 19 Apr 2012 05:57:44 -0500 (CDT) Date: Thu, 19 Apr 2012 12:57:40 +0200 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Satoshi Ogasawara Cc: caml-list@inria.fr Message-ID: <5EE5A4305AC040AABEE680AFA18E0301@erratique.ch> In-Reply-To: References: <4F8D9D0E.1040007@itpl.co.jp> <4F8E1FF4.5070702@itpl.co.jp> <4F8EA91C.3060001@itpl.co.jp> <2B372C89CE4F408688B67B090FA5105C@erratique.ch> <4F8EFC34.7080906@itpl.co.jp> <4F8FD3EB.5050307@itpl.co.jp> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q3JAvpkl013287 Subject: Re: [Caml-list] [ANN] PEC ver. 1.1 Le jeudi, 19 avril 2012 à 12:31, Daniel Bünzli a écrit : > While I'm not very fond of the sub/unscribe part I think it's an interesting implementation and may try, once I get some time, to adapt it to React to see what we can get from it (I also think that the resulting implementation could be much simpler). In fact, if I really understood what you are doing, I think there is a performance problem with your approach. Suppose we have the following configuration where L is a subscribed "leaf" event, that depends on N events that eventually lead to the primitive events P1 ... PN : L | \ ... \ ° ° ° | \ ... \ ° ° ° | \ ... \ ... ... ... | \ \ P1 P2 ... PN If P1 occurs then you start walking back from L, but you don't know where P1 is so you have to walk down every branch until you find P1 and then walk back from there up to L to make the update. Contrast this with (weak) forward pointers: you just start from P1 and walk *once* up to L. Is that correct ? Best, Daniel