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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id F322ABC6B for ; Mon, 11 Feb 2008 15:51:32 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGfvr0fAXQInh2dsb2JhbACQOQEBAQgKKZcx X-IronPort-AV: E=Sophos;i="4.25,333,1199660400"; d="scan'208";a="9031037" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 11 Feb 2008 15:51:32 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m1BEpSLr008408 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 11 Feb 2008 15:51:32 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAN/vr0fUVZgL/2dsb2JhbACoKQ X-IronPort-AV: E=Sophos;i="4.25,333,1199660400"; d="scan'208";a="7905327" Received: from hades.snarc.org ([212.85.152.11]) by mail1-smtp-roc.national.inria.fr with ESMTP; 11 Feb 2008 15:51:32 +0100 Received: by hades.snarc.org (Postfix, from userid 1000) id 6BDA51B482; Mon, 11 Feb 2008 15:51:29 +0100 (CET) Date: Mon, 11 Feb 2008 15:51:29 +0100 To: Jean-Christophe =?iso-8859-1?Q?Filli=E2tre?= Cc: Oliver Bandel , caml-list@inria.fr Subject: Re: [Caml-list] Now it's faster (addendum to "Performance-question") Message-ID: <20080211145129.GA13295@snarc.org> 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> <47B05CFA.80405@lri.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <47B05CFA.80405@lri.fr> X-Warning: Email may contain unsmilyfied humor and/or satire. User-Agent: Mutt/1.5.16 (2007-06-11) From: tab@snarc.org (Vincent Hanquez) X-Miltered: at concorde with ID 47B060F0.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0100,:01 filliatre:01 appending:01 allocations:01 nodes:01 buffer:01 buffer:01 runtime:01 iter:01 chunks:01 char:01 char:01 wrote:01 caml-list:01 surprising:01 On Mon, Feb 11, 2008 at 03:34:34PM +0100, Jean-Christophe Filliātre wrote: > 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. maybe in this case you should add a minimum limit, so that people doesn't create rbuffer with 10 or something. just a simple: let create sz = let sz = max sz my_rbuffer_limit in > > 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). I don't really like removing it either, but people need to know that contents (as in Rbuffer.t -> string) could be evil. > > 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") iterate in a broad sense; beeing able to do something with what's inside the buffer. it could be a list of string, chunks, char, etc ... -- Vincent Hanquez