Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
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
Date: Mon, 2 Aug 1999 22:17:41 +0200	[thread overview]
Message-ID: <19990802221741.63989@pauillac.inria.fr> (raw)
In-Reply-To: <14239.20620.728265.612382@zeppo.csd.uu.se>; from Jens Olsson on Wed, Jul 28, 1999 at 08:48:44PM +0200

> 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




      reply	other threads:[~1999-08-12 10:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-07-28 18:48 Jens Olsson
1999-08-02 20:17 ` Xavier Leroy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19990802221741.63989@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=jenso@csd.uu.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox