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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id C0631BC6B for ; Mon, 11 Feb 2008 13:36:49 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADrQr0fAXQInh2dsb2JhbACQOQEBAQgKKZZK X-IronPort-AV: E=Sophos;i="4.25,333,1199660400"; d="scan'208";a="7899552" Received: from concorde.inria.fr ([192.93.2.39]) by mail1-smtp-roc.national.inria.fr with ESMTP; 11 Feb 2008 13:36:49 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m1BCacIE002170 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 11 Feb 2008 13:36:49 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAALQr0fUVZgL/2dsb2JhbACnQA X-IronPort-AV: E=Sophos;i="4.25,333,1199660400"; d="scan'208";a="9025720" Received: from hades.snarc.org ([212.85.152.11]) by mail3-smtp-sop.national.inria.fr with ESMTP; 11 Feb 2008 13:36:37 +0100 Received: by hades.snarc.org (Postfix, from userid 1000) id 31E171B482; Mon, 11 Feb 2008 13:36:34 +0100 (CET) Date: Mon, 11 Feb 2008 13:36:34 +0100 To: Oliver Bandel Cc: caml-list@inria.fr Subject: Re: [Caml-list] Now it's faster (addendum to "Performance-question") Message-ID: <20080211123633.GA10096@snarc.org> References: <1202297628.47a99b1c7ec53@webmail.in-berlin.de> <1202298904.47a9a018998e4@webmail.in-berlin.de> <20080206120403.GA5335@snarc.org> <1202552291.47ad7de31aa31@webmail.in-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1202552291.47ad7de31aa31@webmail.in-berlin.de> 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 47B04156.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0100,:01 bandel:01 buffer:01 buffer:01 appending:01 avoided:01 imho:01 imho:01 wrote:01 oliver:01 caml-list:01 int:01 strings:01 strings:01 data:02 On Sat, Feb 09, 2008 at 11:18:11AM +0100, Oliver Bandel wrote: > Possibly, but I have no reason to start such an implementation, > if the current possibilities are fast enough. > IMHO optimization comes at the end. When things are working > well and fast enough, optimization is wasted time. > If the software needs optimization, it can be done then. i though that's what you were doing ;) > This is from a practical perspective. > The academic perspective might be different. i was talking on pratical perspective. i don't care about academic research. i seen pratical problem with the 16mb limit, and also breaking the 16mb limit means you have a faster implementation. i'ld though i mentions it, but obviously the buffer is good enough on some usage. > > the buffer library is actually pretty bad since it's actually just a > > simple string. > > IMHO it's differently, but I didn't looked at the code. well i've looked at the code, and it's a string ;) > > each time the buffer need to grow, the string is > > reallocated and the previous one is copied to the new string. > > Are you talking about Buffer-module or the "^"-operator? Buffer module. > I only do use that string to write it to a dbm-database. > I need a certain layout of the strings, because more > than one data-item must be stored for each key. > It's not a complicated format, but the strings must be concated. > I did this with "^" first, because I didn't expected > that the string-stuff needs that much time. I thought my > mathematical operations (statistical things) need most time, > but my expectation was wrong. The calculations were done very fast. > So using Bufeer-module instead of "^" for the concat's > did bring a good performance boost. I wasn't saying the contrary; string concatenation is really really bad for appending obviously, since 1 string is reallocated and 2 are blitted into this new string. obviously the buffer is much faster, because the re-allocation doesn't happens everytimes. But the reallocation can be avoided in another implementation, making thing even faster, depend on the usage you have with your data. > P.S.: > > =============================================== > # Sys.max_string_length;; > - : int = 144115188075855863 > # > =============================================== you're running a 64bit version, so obviously you don't have the 16mb limit. -- Vincent Hanquez