From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id CAA32391; Tue, 3 Jun 2003 02:32:21 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA32486 for ; Tue, 3 Jun 2003 02:32:19 +0200 (MET DST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id h530WIT15129 for ; Tue, 3 Jun 2003 02:32:19 +0200 (MET DST) Received: (qmail 34103 invoked from network); 3 Jun 2003 00:32:17 -0000 Received: from arda.pair.com (HELO checkerdell.d6.com) (209.68.1.133) by relay.pair.com with SMTP; 3 Jun 2003 00:32:17 -0000 X-pair-Authenticated: 209.68.1.133 Message-Id: <4.3.2.7.2.20030602171041.045da898@localhost> X-Sender: checker@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Jun 2003 17:31:46 -0700 To: John Max Skaller , "'caml-list@inria.fr'" From: Chris Hecker Subject: Re: [Caml-list] ocaml and large development projects In-Reply-To: <3EDBBDAF.9090201@ozemail.com.au> References: <4.3.2.7.2.20030517192812.033d9040@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam: no; 0.00; hecker:01 checker:01 caml-list:01 ocamlopt:01 tolerance:99 camlp:01 decoupling:01 ranting:01 stupid:01 checksum:01 cmx:01 inlining:01 compiler:01 chris:01 compilers:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >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 ------------------- 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