From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 5BC317F747 for ; Tue, 19 Aug 2014 14:27:58 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of daniel.buenzli@erratique.ch) identity=pra; client-ip=74.55.86.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="daniel.buenzli@erratique.ch"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of daniel.buenzli@erratique.ch) identity=mailfrom; client-ip=74.55.86.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="daniel.buenzli@erratique.ch"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@smtp.webfaction.com) identity=helo; client-ip=74.55.86.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="postmaster@smtp.webfaction.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioUAO1B81NKN1ZKnGdsb2JhbABZhDeBWoEinCmXQ51aAYEiEAEBAQEBBg0JCRQphAQBBAEjSQoDBQsLGgImAgJHEBkIiCYDCQgErDOVNReBLItzgXozBxaCYzaBHQWEUo1Oh1KJYhiRN2uCTwEBAQ X-IPAS-Result: AioUAO1B81NKN1ZKnGdsb2JhbABZhDeBWoEinCmXQ51aAYEiEAEBAQEBBg0JCRQphAQBBAEjSQoDBQsLGgImAgJHEBkIiCYDCQgErDOVNReBLItzgXozBxaCYzaBHQWEUo1Oh1KJYhiRN2uCTwEBAQ X-IronPort-AV: E=Sophos;i="5.01,893,1400018400"; d="scan'208";a="75226721" Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74]) by mail3-smtp-sop.national.inria.fr with ESMTP; 19 Aug 2014 14:27:57 +0200 Received: from [172.20.10.2] (188.29.164.10.threembb.co.uk [188.29.164.10]) by smtp.webfaction.com (Postfix) with ESMTP id F41BB20E3430; Tue, 19 Aug 2014 12:27:30 +0000 (UTC) Date: Tue, 19 Aug 2014 13:27:27 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: becker.nils@gmx.net Cc: caml-list@inria.fr Message-ID: <1B358C457E1445C0A76B9491809C4C6D@erratique.ch> In-Reply-To: References: X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [Caml-list] using React for -- reactions Le mardi, 19 ao=C3=BBt 2014 =C3=A0 09:34, becker.nils@gmx.net a =C3=A9crit : > is there a run-time cost for large dependency graphs? The runtime cost is depends on the topology of the graph rather than its la= rgeness. Basically given a primitive event/signal update you need in the wo= rst case to do a topological sort of its recursive dependencies on each upd= ate step. But that's really the worst case, as for example if a signal does= n't change its value in the step it's dependents are not updated.=20=20 > reactions are relatively sparse, ie. the number of reactions R=3DO(N), > where N could be from 1e1 to 1e4 or so. so, in each update step only a > small number <10 of dependent molecule numbers and waiting times need to > be updated, even for large systems. in other words, the React-managed > dependency graph is wide (N) but not tall (relatively short dependecy > chains, see above), If it's wide at the *primitive* level then this is a good property for perf= ormance since an update will have little needless work to do. If it is wide= just *after* the primitive for no good reason, i.e. single primitive with = huge number of dependents that filter the primitive and then short dependen= cies, you may want to express the first level of dependents as a primitive = if the filtering nodes entails that only a few of them trigger on an update= . That is sometimes you can gain performance by putting more logic/transfor= mation in your primitives, as it allows you to cut down on the number of no= des or needless updates. > bottom line: can a React based simulation possibly compete with manual, > in-place update of arrays, let's say within a factor of 2? if yes what > do i need to pay attention to? No idea. Basically you need to pay attention to the topology of your graph.= Is your code published somewhere ?=20=20 Best, Daniel