From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: christophe.raffalli@univ-savoie.fr
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] large parametrized polymorphic variant type combinations take forever to compile
Date: Tue, 10 Jul 2007 16:31:42 +0900 (JST) [thread overview]
Message-ID: <20070710.163142.68036861.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <469330B3.4080005@univ-savoie.fr>
From: Christophe Raffalli <christophe.raffalli@univ-savoie.fr>
> > Are you using the CVS 3.10 version?
> > Performance has been been improved, but as I already answerred you,
> > complexity for polymorphic variant pattern-matching is still O(n*n),
>
> This looks strange: OCaml compute useless cases and incomplete pattern
> and since you can encode SAT in that, I would think that OCaml
> pattern matching (with monomorphic or polymorphic variant) would be
> exponential ... OK, this is for large patterns, not just case analysis.
I didn't express myself correctly. I was talking about the complexity
of _typing_ a pattern matching. The completeness check can be of
course much more expensive, if you check for a combination of
patterns, like in you example.
Something like:
let f =
function
`A, `A -> ()
| #Foo.t as x, `A -> Foo.conv x
| `A, (#Foo.t as x) -> Foo.conv x
| #Foo.t as x, (#Foo.t as y) -> Foo.conv x; Foo.conv y
where Foo.t is composed of 600 constant cases,
takes 90s in the already improved CVS version,
while
let f =
function #Foo.t as x -> Foo.conv x | #Foo.t as x -> Foo.conv x
just takes 1.6s
Fortunately it seems that people who use huge types do not check for
combinations of patterns, but just discriminate on a single variant
type...
Jacques Garrigue
next prev parent reply other threads:[~2007-07-10 7:32 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-06 16:30 compiling large file hogs RAM and takes a long time Sam Steingold
2007-06-06 16:51 ` [Caml-list] " skaller
2007-06-06 17:05 ` Sam Steingold
2007-06-07 15:52 ` Sam Steingold
2007-06-08 1:02 ` [Caml-list] " Jacques Garrigue
2007-06-08 1:51 ` skaller
2007-06-08 2:26 ` Yaron Minsky
2007-06-08 9:05 ` Thomas Fischbacher
2007-06-08 9:35 ` skaller
2007-06-08 9:55 ` Thomas Fischbacher
2007-06-08 13:39 ` Sam Steingold
2007-06-08 12:30 ` [Caml-list] " Jacques Garrigue
2007-06-15 15:41 ` Sam Steingold
2007-06-15 18:56 ` [Caml-list] " Jon Harrop
2007-06-15 20:06 ` Sam Steingold
2007-07-09 20:22 ` large parametrized polymorphic variant type combinations take forever to compile Sam Steingold
2007-07-09 22:45 ` Sam Steingold
2007-07-09 23:37 ` [Caml-list] " Jacques Garrigue
2007-07-10 7:09 ` Christophe Raffalli
2007-07-10 7:31 ` Jacques Garrigue [this message]
2007-07-10 14:16 ` Sam Steingold
2007-07-10 16:49 ` Sam Steingold
[not found] ` <46938BDA.1090605@podval.org>
2007-07-11 0:10 ` [Caml-list] " Jacques Garrigue
2007-07-11 1:19 ` Jon Harrop
2007-07-11 2:23 ` Jacques GARRIGUE
2007-07-11 13:12 ` Sam Steingold
2007-07-11 19:17 ` [Caml-list] " Jon Harrop
2007-07-10 3:34 ` [Caml-list] " skaller
2007-07-10 13:27 ` Sam Steingold
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=20070710.163142.68036861.garrigue@math.nagoya-u.ac.jp \
--to=garrigue@math.nagoya-u.ac.jp \
--cc=caml-list@inria.fr \
--cc=christophe.raffalli@univ-savoie.fr \
/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