From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 3B8FCBC6B for ; Mon, 11 Feb 2008 15:34:33 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKfrr0fAXQImh2dsb2JhbACQOQEBAQgKKZcd X-IronPort-AV: E=Sophos;i="4.25,333,1199660400"; d="scan'208";a="22473740" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 11 Feb 2008 15:34:32 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m1BEYWLc018574 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 11 Feb 2008 15:34:32 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGvrr0eBrw8Eh2dsb2JhbACQOQEBAQgKKZci X-IronPort-AV: E=Sophos;i="4.25,333,1199660400"; d="scan'208";a="7165385" Received: from ext.lri.fr ([129.175.15.4]) by mail2-smtp-roc.national.inria.fr with ESMTP; 11 Feb 2008 15:34:32 +0100 Received: from localhost (localhost [127.0.0.1]) by ext.lri.fr (Postfix) with ESMTP id E969CA4923; Mon, 11 Feb 2008 15:34:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at lri.fr Received: from ext.lri.fr ([127.0.0.1]) by localhost (ext.lri.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FAcS1mtslLX; Mon, 11 Feb 2008 15:32:17 +0100 (CET) Received: from [129.175.4.117] (lri4-117 [129.175.4.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ext.lri.fr (Postfix) with ESMTP id B15D1A490D; Mon, 11 Feb 2008 15:32:17 +0100 (CET) Message-ID: <47B05CFA.80405@lri.fr> Date: Mon, 11 Feb 2008 15:34:34 +0100 From: =?ISO-8859-1?Q?Jean-Christophe_Filli=E2tre?= User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Vincent Hanquez Cc: Oliver Bandel , caml-list@inria.fr Subject: Re: [Caml-list] Now it's faster (addendum to "Performance-question") References: <1202297628.47a99b1c7ec53@webmail.in-berlin.de> <1202298904.47a9a018998e4@webmail.in-berlin.de> <20080206120403.GA5335@snarc.org> <47B01D01.7040509@lri.fr> <20080211124153.GB10096@snarc.org> In-Reply-To: <20080211124153.GB10096@snarc.org> X-Enigmail-Version: 0.94.2.0 OpenPGP: url=http://www.lri.fr/~filliatr/mykey.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Miltered: at discorde with ID 47B05CF8.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; filliatre:01 filliatre:01 lri:01 0100,:01 buffer:01 buffer:01 appending:01 allocations:01 nodes:01 runtime:01 iter:01 lri:01 filliatr:01 char:01 wrote:01 Vincent Hanquez wrote: > On Mon, Feb 11, 2008 at 11:01:37AM +0100, Jean-Christophe Filliātre wrote: >> Just for fun, I wrote a ropes-based implementation of Buffer. The >> interface is exactly the same. Differences between the two >> implementations are the following: > > that's nice. how's the performance compare to plain buffer ? I made few tests, but performance since to be roughly the same. But there is a caveat: when creating a buffer, the value passed to create does not have the same meaning as in Buffer, and may result in bad performances if it is too small. With Buffer, it will be doubled until the buffer is large enough, involving a few string copies. With Rbuffer, the value passed to create is the size of each chunk in the rope (roughly), so passing a value such as 10 and then appending millions of characters will result in a lot of allocations for rope nodes, and will make Rbuffer less efficient than Buffer. But if you pass a value large enough, i.e. of the same order of magnitude as the size of the final buffer, then it should be as efficient as Buffer. > one nit, keeping compatibility is good, however, the contents function > is quite evil (runtime failure), and removing it would be nice as well. I agree that a failure of "contents" can be surprising, but I don't like the idea of removing it at all (in particular because you may want to be able to substitute Rbuffer for Buffer in yours programs to compare efficiencies). > people should use other thing to "iterate" over the contents (even if > contents is quite practical) do you mean something like "iter : t -> (char -> unit) -> unit"? (It could be implemented more efficiently than a repeated use of "nth") -- Jean-Christophe Filliātre http://www.lri.fr/~filliatr/