Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: comp.lang.c Subject: Re: C common practice. (was: low level optimization) Message-ID: Date: 30 Apr 91 14:37:32 GMT References: <22354@lanl.gov> <16815@chaph.usc.edu> <22649@lanl.gov> <1991Apr29.220139.28983@cbnewsh.att.com> Sender: news@OSF.ORG Organization: Open Software Foundation Lines: 34 In-reply-to: daw@cbnewsh.att.com's message of 29 Apr 91 22:01:39 GMT In article <1991Apr29.220139.28983@cbnewsh.att.com> daw@cbnewsh.att.com (David Wolverton) writes: | In article <22649@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes: | > One of the assumptions (which is still valid most places) is that | > no interprocedural analysis is done - even _within_ a file, even | > though the language permits such optimizations. The result is that | > there really is a tendency to maintain C code as numerous separate | > files. ...[stuff deleted]... | > I don't maintain that keeping code in separate file is necessarily | > bad or good. But to pretend that it is not common practice is to | > ignore reality. This common practice may in (the near) future result | > in less efficient code because of missed optimization. | | I can't say about "most places", but I _can_ say that we | built a commercially-available 3B2 C compiler here in 1986 | that did some interprocedural stuff within a source file. | | Our biggest customer was a project with _thousands_ of | functions, one per file. We tried mightily to get them | to group related functions into a single file, but their | "project methodology" wouldn't allow it. So they could | never take advantage of that group of optimizations. One way to 'solve' this problem is to have one file #include each of the different .c files. That way for debugging, you get fast turnaround time (only recompile each file that changed in the typical fashion), and for production you get interprocedural optimizations. Note typically for compiling everything together, you typically need lots of physical memory to run the compiler. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?