caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: sds@gnu.org, caml-list@inria.fr
Subject: Re: [Caml-list] Re: compiling large file hogs RAM and takes a long time.
Date: Fri, 08 Jun 2007 11:51:40 +1000	[thread overview]
Message-ID: <1181267500.15201.144.camel@rosella.wigram> (raw)
In-Reply-To: <20070608.100255.84973407.garrigue@math.nagoya-u.ac.jp>

On Fri, 2007-06-08 at 10:02 +0900, Jacques Garrigue wrote:
> > 
> > Any chance there is some quadratic code in polymorphic variant type
> > processing?!
> 
> There is, and this is a known problem:
>   http://caml.inria.fr/mantis/view.php?id=4053
> 
> I'm sorry, but I don't see any easy way out.
> At least on the basic time complexity.

You mention in the ticket there is a hard way out .. using
binary trees; hard because it would require changes everywhere
in the compiler. Is this actually enough? Seems to reduce

	O(n * n * log n)

to 

	O( n * log n * log n)

which is still pretty bad.. is that right?

How about a one level digital lookup, that is, use the first
8 bits of the key to choose one of 256 binary trees?

In commercial code O() performance isn't usually that relevant.
Hybrid data structure is probably best, even if the O() performance
is worse: if a one level digital lookup reduces quadratic time
by 256 that reduces a 4 hour compilation to 1 minute.. :)

Then 1,000-10,000 type constructors would be handled easily, although
around 100,000 you'd be trouble again .. but I think you'd be in
trouble anyhow if you had that many!

Also .. I suspect the OP is only using polymorphic variants to 
work around the 246 constructor limitation on non-polymorphic variants.
In this case, they could just use factored non-polymorphic variants.

the point being: polymorphic variants should be used when you need
polymorphism and are willing to pay the price. This is typically
in a compiler or some other system where there are only a moderate
number of constructors, but many ways to combine them.

So maybe the correct fix isn't to modify polymorphic variants ..
but to repair the 246 limitation on non-polymorphic variants
by automatically factoring them .. it is, after all, entirely
syntactic sugar. Of course there's be a run time penalty from
double indirection .. but that's the price you pay for extremely
fast single indirected non-polymorphic variants when the number
of constructors is small.

Hmm .. and this could 'almost' be done with camlp4.. :)

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


  reply	other threads:[~2007-06-08  1:51 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-06 16:30 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 [this message]
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
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=1181267500.15201.144.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=garrigue@math.nagoya-u.ac.jp \
    --cc=sds@gnu.org \
    /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;
as well as URLs for NNTP newsgroup(s).