From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2E5Xnlm026007 for ; Wed, 14 Mar 2012 06:33:49 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUDAIQsYE/RVdK2kWdsb2JhbABDpDiRRggiAQEBAQkJDQcSKYIJAQEBAwESAiwBGxILAQMBCwYFCwMKDSEiAREBBQEKEgYTCQkQh2MFC544Cot+gnGFEj+IdAEFC5BtBJVWjkg9hAg X-IronPort-AV: E=Sophos;i="4.73,582,1325458800"; d="scan'208";a="149241144" Received: from mail-iy0-f182.google.com ([209.85.210.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 14 Mar 2012 06:33:43 +0100 Received: by mail-iy0-f182.google.com with SMTP id k25so2993423iah.27 for ; Tue, 13 Mar 2012 22:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=7yDsMself38I6r3iswMsEDsNwPbTANIvgse0DW3mzHo=; b=EXTa/cfiIp7bS6jzt/PeHCzP0d/47d0Bo9GAuWhjm/raxGGOHoVPtlsgeBW5Pg4e72 GToMfJ/B9N+TCSuczwqzBxi5/JIhnynvUEnKxDsJxNd4Aj5OpyRPl/eieoHj05x/P1sc aTezIjbby+pS+wwXrt7FKlNeJDBqb3CKm8H59oCc/b4FTDo4QH7WS7FjUUuc7/iALxLt 8quWoU9estB6IwKHdC8CSBquT7N4SPVOKFJd1OegFqPsFseeDJUjqLai0awPOwPBriKo LbH3KVl1jNknNVjMlwkszadDKAwVtNekd58+fFWkfSIetkAT7lCU+ui4piaXRaDWQheg +RNw== Received: by 10.50.77.138 with SMTP id s10mr2095899igw.48.1331703222894; Tue, 13 Mar 2012 22:33:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.3.38 with HTTP; Tue, 13 Mar 2012 22:33:02 -0700 (PDT) In-Reply-To: References: <20120313220202.GA29196@kiuru> From: Gabriel Scherer Date: Wed, 14 Mar 2012 06:33:02 +0100 Message-ID: To: Gerd Stolpmann Cc: Matti Jokinen , Raphael Proust , SerP , caml-list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q2E5Xnlm026007 Subject: Re: [Caml-list] Very slow compilation This heavily depends on the structure of the code, and different shapes of code will cause trouble to the type-checker or the backend. Left-nesting lets (let x = let y = let z = .... in ... in ... in ...) can generate known exponential worse case for type inference. Nesting loops (I recently encountered code written by a student that had innocently nested 20 for loops from 0 to 1...) can trouble ocamlopt compilation passes. Long code can be fine (linear compilation time or, in the bad cases, polynomial), it's when a particularly vicious kind of nesting causes exponential compile times that you're in trouble. But when the problem is in the backend, splitting some things into independent functions should be a very effective workaround. On Tue, Mar 13, 2012 at 11:46 PM, Gerd Stolpmann wrote: > >>> When working with ocamlduce (a few years ago) the same problem was >>> raised. A simple thing that can greatly reduce typing time is putting >>> explicit type annotations. Although the verbosity is increased it is >>> not that much of a burden if the annotated parts do not evolve too >>> much. >> >> In my experience, ocamlduceopt/ocamlduceopt.opt slows down regularly when >> the source file approaches 1000 lines of OCamlDuce code.  The compilation >> time then grows rapidly: in this machine (Thinkpad R5000) 1000 lines >> took 20 seconds, 2000 lines 2 minutes, 3000 lines hanged the system. >> Only OCamlDuce code causes slowdown, pure OCaml is compiled rapidly even >> by OCamlDuce compilers. >> >> However, it is not typechecking that takes time.  The time-consuming >> step appears to be register allocation.  Try: > > I've observed the same problem with code generated by the Hydro RPC > library (using standard ocamlopt). This library can generate a very long > set of mutually recursive functions, and the time spent by ocamlopt seemed > to explode (compilation took minutes). ocamlc was not affected. > > The fix was to change the code generator, and to break the recursion into > smaller pieces. > >> ocamldebug /usr/bin/ocamlduceopt -c big_ocamlduce_module.ml >> run >> ... wait about two minutes and press control-C >> >> You will probably find the compiler executing a function from modules >> such as Interf, Coloring or Spill, or a lower level function called >> from these modules. > > This was also my observation. > >> I have never observed anything similar in OCaml, but ocamlduceopt >> appears to use unmodified ocamlopt code generation modules.  I wonder >> what is the critical difference between OCamlDuce code and typical >> OCaml code at this level. > > I guess the only difference is the length of the code passed at once to > the backend, since you can generate code showing this problem for standard > ocamlopt, as in my Hydro case. > > Gerd > >> >> - Matti Jokinen >> >> -- >> Caml-list mailing list.  Subscription management and archives: >> https://sympa-roc.inria.fr/wws/info/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs >> >> >> > > > -- > Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de > Creator of GODI and camlcity.org. > Contact details:        http://www.camlcity.org/contact.html > Company homepage:       http://www.gerd-stolpmann.de > *** Searching for new projects! Need consulting for system > *** programming in Ocaml? Gerd Stolpmann can help you. > > > > -- > Caml-list mailing list.  Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >