From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA09060 for caml-redistribution; Thu, 12 Aug 1999 12:08:12 +0200 (MET DST)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA14976 for <caml-list@pauillac.inria.fr>; Mon, 2 Aug 1999 22:21:09 +0200 (MET DST)
Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35])
	by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id WAA11051;
	Mon, 2 Aug 1999 22:17:43 +0200 (MET DST)
Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA06168; Mon, 2 Aug 1999 22:17:41 +0200 (MET DST)
Message-ID: <19990802221741.63989@pauillac.inria.fr>
Date: Mon, 2 Aug 1999 22:17:41 +0200
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Jens Olsson <jenso@csd.uu.se>, caml-list@inria.fr
Subject: Re: tuple vs curried, records vs variants
References: <14239.20620.728265.612382@zeppo.csd.uu.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1
In-Reply-To: <14239.20620.728265.612382@zeppo.csd.uu.se>; from Jens Olsson on Wed, Jul 28, 1999 at 08:48:44PM +0200
Sender: weis

> Different sources (such as the documentation) says curried functions
> are to prefer rather than functions using tuples, if speed is of any
> concern anyway.

This is definitely true for the bytecode compiler, which can execute
curried function applications with no heap allocation at all in the
common cases, while building a tuple of arguments always entail some
heap allocation.

For the native-code compiler, an optimization for "tupled" function
calls was added some time ago, which removes the heap allocation
of the tuple of arguments in the case of calls to "known" functions.
There are still some cases of unknown function calls where the curried
form is more efficient than the tupled form, but it shouldn't make a
big difference.

Note that this discussion assumes that the tuple of arguments needs
rebuilding at each call.  If you often pass the tuple of arguments
unmodified to another function, as in

        let f ((x,y,z) as t) = ... g t ... h t ...

the cost of allocating the tuple is amortized on several calls, and
the fact that only one argument needs to be passed to each function
may further decrease the cost.

> Upon a question regarding speed I also got the
> recommendation to use records instead of a variant with a single
> constructor.

The only case where it matters is if all fields of the record have
type "float".  In this case, the record will be represented, accessed
and built more efficiently than the one-constructor variant.  In all
other situations, the compilers generate pretty much the same code for
both styles.

> After making all the functions curried instead, and changing the
> implementation to use records instead I measured the performance of
> the two implementation and realized to my surprise that the old
> version (the implementation using variants and tupled functions) was
> faster (than the one using records and curried functions).

I would have to see the code to try and understand what's happening.

> 3) BTW, what is the "best" way of writing pattern-matching functions,
>    ie   [let f x = match ....] or [let f = function x -> ...]?
>    (Maybe we're getting 'religious' here as well?)

Much more so here, because the compilers will generate identical code
for the two forms, so it's purely a matter of syntactic taste.

Best regards,

- Xavier Leroy