English version
Accueil     Ŕ propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis ŕ jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml ŕ l'adresse ocaml.org.

Browse thread
[Caml-list] ocaml and large development projects
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-05-18 (16:00)
From: Ville-Pertti Keinonen <will@e...>
Subject: Re: [Caml-list] ocaml and large development projects

> I do agree that there should be an option to disable cross-file
> inlining.  Somehow that would have to be coordinated with the
> dependencies.  I don't know if this would be easy to implement, though,
> since I don't think the code doing the inlining knows where the
> functions came from.

Preventing dependencies between compilation units would also require 
preventing constant values from being picked up.

> In my experience, it isn't as bad as you make it sound like.  Touching
> early modules doesn't cause a recompile of everything, only modules 
> that
> directly depend on it.  The inlining seems to only happen to one level.

Are you sure?  You could probably get make to do that by depending on 
.ml files instead of .cmx files, but that isn't what ocamldep generates.

> There are a few C compilers that support cross-file inlining, but the
> ones that I know of do it at "link" time.  So instead of extra
> recompiles of source files, you end up with extremely long link times,
> since it is doing the global analysis of everything each time you link.

Some C compilers support inlining across compilation units when you 
compile multiple files at a time, i.e. cc *.c can produce better 
optimized code than the equivalent compiled using a reasonable Makefile.

I doubt that many people make use of such features in C compilers other 
than for benchmarks.  Not because it isn't a useful optimization in 
general, but because C/C++ programming practices work around it by 
putting more things in header files.

To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners