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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id AFDFBBC6C for ; Sat, 9 Feb 2008 11:03:06 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOYIrUfAXQInh2dsb2JhbACQNgEBCQopl28 X-IronPort-AV: E=Sophos;i="4.25,326,1199660400"; d="scan'208";a="7121485" Received: from concorde.inria.fr ([192.93.2.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 09 Feb 2008 11:03:06 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m19A31T2028400 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Sat, 9 Feb 2008 11:03:06 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAF4JrUfAbSoIY2dsb2JhbACQKQMVBAYml3M X-IronPort-AV: E=Sophos;i="4.25,326,1199660400"; d="scan'208";a="22426619" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail4-smtp-sop.national.inria.fr with ESMTP; 09 Feb 2008 11:03:01 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from einhorn.in-berlin.de (localhost [127.0.0.1]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id m19A30kA014818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 9 Feb 2008 11:03:00 +0100 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id m19A30IM014816 for caml-list@inria.fr; Sat, 9 Feb 2008 11:03:00 +0100 X-Authentication-Warning: einhorn.in-berlin.de: www-data set sender to oliver@first.in-berlin.de using -f Received: from dslb-088-073-071-100.pools.arcor-ip.net (dslb-088-073-071-100.pools.arcor-ip.net [88.73.71.100]) by webmail.in-berlin.de (IMP) with HTTP for ; Sat, 9 Feb 2008 11:03:00 +0100 Message-ID: <1202551380.47ad7a5482948@webmail.in-berlin.de> Date: Sat, 9 Feb 2008 11:03:00 +0100 From: Oliver Bandel To: 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> <1202378134.6444.1.camel@Blefuscu> In-Reply-To: <1202378134.6444.1.camel@Blefuscu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Miltered: at concorde with ID 47AD7A55.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bandel:01 in-berlin:01 buffer:01 buffer:01 univ-orleans:01 cheers:01 0100,:01 appending:01 univ-orleans:01 lifo:01 beginner's:01 ocaml:01 bug:01 liquidations:98 beginners:01 Well, I didn't say the buffer library is slow. I said, it's much faster than using "^". For not-that-intensive string-concat's, 2^" is fast enough, but when you do often concat strings, then buffer-module is faster. Do you mean the buffer module should be made better or do you think, the "^" operator should be implemented differently? If Buffer-module might be even faster, when it's changed, that's fine, but IMHO it's quite fast. Ciao, Oliver Zitat von David Teller : > A possible improvement of the buffer library (along with a ropes > library) may be a good future subject for OSR. Well, once we have > answered the already-asked questions, of course. > > Cheers, > David > > On Wed, 2008-02-06 at 13:04 +0100, Vincent Hanquez wrote: > > well i'm pretty sure you could go down even further with your own > > implementation of a buffer library. > > > > the buffer library is actually pretty bad since it's actually just > a > > simple string. each time the buffer need to grow, the string is > > reallocated and the previous one is copied to the new string. > > and you got the 16mb limit (max_string_length) on 32bit. > > > > if you implement a growing array of fixed sized string (4K for > example), > > you just don't need to copy data each time your buffer need to > grow. I > > suspect it might be even faster than the normal buffer in your case > > (lots of data appending), but depends on what you do with your > buffer > > afterwards. > > > -- > David Teller > Security of Distributed Systems > http://www.univ-orleans.fr/lifo/Members/David.Teller > Angry researcher: French Universities need reforms, but the LRU act > brings liquidations. > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >