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 <i...@gerd-stolpmann.de> 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 g...@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 > -- 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
