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-06-03 (00:32)
From: Chris Hecker <checker@d...>
Subject: Re: [Caml-list] ocaml and large development projects

>In other words, don't worry about it. Ocaml is FAST. [...]
>So you are expecting poor performance where it
>simply doesn't exist.

Uh, I must have missed it when you stopped by my office and came to this 
conclusion from looking at actual data from my project instead of just 
asserting it on a mailing list.  :)  Another example of 

Actually, ocamlopt compile speeds are already a problem for me, and my 
project is only about 20% done, LOC-wise.  This is a small problem for me 
now that's going to be a huge problem soon enough unless I can get it 
fixed.  Perhaps I have a lower process-overhead tolerance than you.  I've 
already had to change my project around so only the files that need it use 
camlp4 (for streams) because it was too slow.  I was counting on ocamlopt 
working "correctly" and allowing this decoupling as well, and again, I'm 
amazed it doesn't.  I'm hoping that the ocaml team takes this seriously and 
fixes it soon (although no one from Inria has responded to this thread, 
which worries me).

>[lots of ranting about software houses snipped]

In spite of these generalizations about developers and organizations, it is 
not hard in C++ to decouple a large project.  All C++ compilers support 
this "feature".  It's done every day in large projects, and it mostly 
works.  It appears impossible with ocamlopt given the current state of the 
compiler.  There is a fundamental and important difference between "often 
people don't do it in C++ and John thinks they're stupid" and "it is 
physically impossible to do so in ocaml".

Anyway, back to the problem:  it seems like the hacked way to enable this 
is to checksum the cmi and compare the new one to the old one and if they 
match then don't update the new one during cmx compilation.  That, coupled 
with a way to disable code inlining would allow you to control decoupling 
fairly well.  Unless I'm missing something; I haven't looked into this yet 
(we had a baby :).


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