From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id E6CCEBC84 for ; Thu, 17 Mar 2005 11:20:08 +0100 (CET) Received: from first.in-berlin.de (dialin-145-254-054-177.arcor-ip.net [145.254.54.177]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j2HAK6ZI022430 for ; Thu, 17 Mar 2005 11:20:07 +0100 Received: by first.in-berlin.de (Postfix, from userid 501) id 96037BC2BF; Thu, 17 Mar 2005 01:21:09 +0100 (CET) Date: Thu, 17 Mar 2005 01:21:09 +0100 From: Oliver Bandel To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OCaml troll on Slashdot Message-ID: <20050317002109.GD439@first.in-berlin.de> References: <20050316001819.GB347@first.in-berlin.de> <200503160301.11138.jon@ffconsultancy.com> <20050316.224108.35690658.garrigue@math.nagoya-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Miltered: at nez-perce with ID 423959D6.003 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; oliver:01 bandel:01 oliver:01 in-berlin:01 caml-list:01 ocaml:01 irisa:01 ocaml:01 recursive:01 inputs:01 recursive:01 wrote:01 wrote:01 writes:01 short:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.3 required=5.0 tests=DATE_IN_PAST_06_12, FORGED_RCVD_HELO autolearn=disabled version=3.0.2 X-Spam-Level: On Wed, Mar 16, 2005 at 09:43:42AM -0800, brogoff wrote: > On Wed, 16 Mar 2005, Jacques Garrigue wrote: > > From: Yoann Padioleau > > > Jon Harrop writes: > > > > In OCaml, non-tail-recursive functions are often faster than their tail > > > > recursive equivalents for small inputs (e.g. short lists). > > > > > > really ? why ? > > > > Because tail-recursive versions do some extra work to ensure > > tail-recursiveness. For instance building a list in reverse order, and > > converting it back with List.rev at the end. This only pays off for > > huge lists. > > No doubt the implementors will want me guillotined for bringing this up again, > but using the (still functional!) set_cdr! tail recursive functions, which do > *not* reverse the list, are always faster than the non tail recursive > list functions, even for small lists, at least in my experience. And I experienced, that adding a "_rev" at the end of a function often makes more sense than adding a List.rev inside. Often some code produces a list and gives it to a function that again creates a list, based on that data. Then "_rev"^2 means _orig and all is going well. If there are an odd number of "_rev"-functions, a List.rev can be added *THEN* (instead of always feel the necessity to provide "_orig"-functions instead of "_rev"-functions. Ciao, Oliver