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 XAA28507; Mon, 2 Jun 2003 23:24:55 +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 XAA28455 for ; Mon, 2 Jun 2003 23:24:54 +0200 (MET DST) Received: from mail1.tpgi.com.au (mail.tpgi.com.au [203.12.160.57]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h52LOpT07047 for ; Mon, 2 Jun 2003 23:24:52 +0200 (MET DST) Received: from ozemail.com.au (203-219-234-174-syd-ts25-2600.tpgi.com.au [203.219.234.174]) (authenticated (0 bits)) by mail1.tpgi.com.au (8.11.6/8.11.6) with ESMTP id h52LOlT25138 for ; Tue, 3 Jun 2003 07:24:47 +1000 Message-ID: <3EDBC09F.2080403@ozemail.com.au> Date: Tue, 03 Jun 2003 07:24:47 +1000 From: John Max Skaller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: "'caml-list@inria.fr'" Subject: Re: [Caml-list] ocaml and large development projects References: <4.3.2.7.2.20030517192812.033d9040@localhost> <4.3.2.7.2.20030517192812.033d9040@localhost> <4.3.2.7.2.20030517225010.04b748a0@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ozemail:01 caml-list:01 hecker:01 inlining:01 compiles:01 everying:01 selectively:01 instantiate:01 model:01 unexpected:01 slowness:01 inference:01 toxteth:01 glebe:01 2037,:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Chris Hecker wrote: > >> > Uh, isn't this a major flaw in the compiler? Why does this happen? >> Inlining. Inlining is an important optimization, especially for >> functional languages, where many functions are typically short. > > > Sure, but there has to be a better way to do this than forcing a > recompile of the entire program when you change a debug print in your > lowest level completely encapsulated library. That's insanely bad > software engineering, and this is a huge issue. No it isn't. With due respect, Chris, you come from the C++ world where compiles take an hour, the NFS service is screwed, and everyone is alway rebuilding everying in a totally unmodular fashion. So you are expecting poor performance where it simply doesn't exist. This is not C++ where you #include the whole of the standard library and half the rest of the world in every small translation unit and have to recompile the interface from TEXT every time. This is Ocaml where you can selectively include module interfaces which have been already compiled. So compiles of tranlsation units (ml files) are very very fast because 90% of the work a C++ compiler does is recompile the same thing over and over again ...... Added to that Ocaml has a simpler language structure, and doesn't need to instantiate 10000 templates .. Trust me. Don't worry about it! The existing compiler performance optimisations and separate compilation model have superb performance from an engineering viewpoint (if there is a weakness it is in the unexpected slowness of inference of some nasty types, which occasionally bites you) -- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- 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