On Mon, 02 Jun 2003 17:31:46 -0700
Chris Hecker <checker@d6.com> wrote:

> 
> >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 
> You-Don't-Need-This-itis.
> 
> 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 :).
> 
> Chris

Have you thought of trying to use Gerd Stolpmann's Dl package?  Although that's
not exactly its purpose you'll be able to use it to implement each module in
a separate shared library.  It's fairly trivial to adapt it to work on win32.

In order to generate the loader for each part, you use:

ocamldlgen original_implementation.ml implementing_library.dll > stub_impl.ml

And build your bits as dlls with something like:

ocamlopt -pack <*.cmx> -output-obj -o packed.obj
link /dll /out:implementing_library.dll packed.obj $(LIBS)

This would allow you to separate your project into as many separately compiled
subparts as you want without sacrificing inlining within the parts.

-- 
`No, you don't understand,' the Knight said, looking a little vexed. 
`That's what the name is called. The name really is "The Aged Aged 
Man."'
-- Lewis Carroll

-------------------
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