jack@cca.CCA.COM (Jack Orenstein) (05/14/88)
I'm working on a program whose load module takes up about 130K. It's composed from about 40 modules organized into four libraries (created with lb). The link (ld) step takes too much time. Experimenting with flags with this much code will take a huge amount of time, so I'm hoping someone else knows this: Are there any compiler or linker flags I should be using that would speed up the link step? (E.g. large memory model?) I already have everything in vd0:. Jack Orenstein
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/14/88)
>I'm working on a program whose load module takes up about 130K. It's >composed from about 40 modules organized into four libraries (created >with lb). The link (ld) step takes too much time. Experimenting with >flags with this much code will take a huge amount of time, so I'm hoping >someone else knows this: Are there any compiler or linker flags I should >be using that would speed up the link step? (E.g. large memory model?) > >I already have everything in vd0:. > >Jack Orenstein 40 modules? Sounds like some of those should be libraries... link libraries that is. Take a logical subset of modules which you are no longer modifying (or not modifying very often) and create a link library out of it. Another fix would be to change your programming habits... 40 modules for only a 130K load module???? Also, try putting your objects in RAM: ... RAM: is much faster than VD0: (6x faster, in fact). I always put temporary or regeneratable files in RAM:. Still, since you have 40 object modules, you might want to keep them in Vd0:, and only copy them to RAM: to link them. -Matt
jack@cca.CCA.COM (Jack Orenstein) (05/16/88)
In article <8805132300.AA26431@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > 40 modules? Sounds like some of those should be libraries... >link libraries that is. I'm already doing that. I have four libraries. >are no longer modifying (or not modifying very often) and create a link >library out of it. Another fix would be to change your programming >habits... 40 modules for only a 130K load module???? Would this really help? Wouldn't that give me fewer modules that take longer to load, not affecting total time? (And I like my habits. Did Picasso listen when they said "too much blue"?) > Also, try putting your objects in RAM: ... RAM: is much faster >than VD0: (6x faster, in fact). I always put temporary or regeneratable >files in RAM:. Still, since you have 40 object modules, you might want >to keep them in Vd0:, and only copy them to RAM: to link them. Thanks - someone else suggested that too. I wasn't aware of the huge difference in speed between vd0: and ram: But I'm still wondering about the flags. Will the large memory module or any other flags further improve speed? Jack Orenstein
doug-merritt@cup.portal.com (05/18/88)
Matt Dillon wrote: >> [...] Another fix would be to change your programming >>habits... 40 modules for only a 130K load module???? Jack Orenstein replied: >I like my habits. Did Picasso listen when they said "too much blue"? Although to some extent this is a matter of personal preference, I can't see suggesting to people that they change to a "monolithic" programming habit. We all know that Modularity Is A Good Thing, right? Consider that in C, the scoping of variables is limited to one of: 1) global, 2) functions, or 3) to files. We also know that global variables are The Root Of All Evil (ok, so I use 'em sometimes...). Let's assume that everyone uses information hiding principles in functions when possible to avoid those Evil Global Variables, so we're in good shape with variables that are local to functions. That leaves function and variable names that must be shared between several functions, but aren't shared universally. The Good True And Right way to treat these in C is to bundle them up into a file, and make all functions and "global" variables in that file static to hide their names from Evil Wrongdoers In Other Modules, and leave just a minimal amount of interface namespace global. In other words, other things being equal, someone with lots of little C files is probably doing a better job of implementing structured programming information hiding principles than someone who has a small number of huge C files (present company excepted, of course :-). We don't know for *sure* that Jack is one of the Good Guys In White, but he's innocent until proven guilty. And you certainly don't want to ask him to put on a black hat! Jack, by all means, *please* stick with your current habits! We could do worse than to create a new (or several new) libraries for each of our large projects. Matt, I'm only criticizing your suggestion to Jack, not your actual programming style...From some of your designs I remember seeing, it's clear that you're a good programmer. And your software's functionality is marvelous anyway; I just figure someone's gotta throw in the obligatory comments about modern programming methodologies. Creating large modules is a sin that some of us (like me) commit sometimes, but we shouldn't advocate it. Doug --- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/19/88)
:We all know that Modularity Is A Good Thing, right? Consider that in :C, the scoping of variables is limited to one of: 1) global, 2) functions, :or 3) to files. We also know that global variables are The Root Of All Evil :(ok, so I use 'em sometimes...). Let's assume that everyone uses :information hiding principles in functions when possible to avoid those :Evil Global Variables, so we're in good shape with variables that are :local to functions. Just because a particular variable may have a large scope doesn't mean you must use or assume it as such. Although it *is* nice to be absolutely sure of something (i.e. the language doesn't allow the variable to be any more than what you use it for), you get equivalent results by sticking in a two line comment at the beginning of your code telling other programmers 'Hey, I'm defining static variables in this file but only the ones defined at the top will be used by all the routines in this file.... those static variables defined in the middle of the file will be used only within a particular section and not beyond that'... Or something to that extent. Usually such practices are obvious even without the comment, and certainly the programmer knows *exactly* what he is doing. :In other words, other things being equal, someone with lots of little C :files is probably doing a better job of implementing structured programming :information hiding principles than someone who has a small number of :huge C files (present company excepted, of course :-). Unless he makes the source unreadable and difficult to manage by overly breaking it up. Don't get caught up in the theory.... structured programming isn't just restrictions in the language... in fact, structured programming is more personal style than anything else, and language restrictions can almost be ignored. It really comes down to how good a programmer one is... the 'bad' programmer is going to write bad code no matter what structural constraints are placed on him. (This is a general comment... I've never seen the original poster's code so I can hardly have an opinion on it!!). :Matt, I'm only criticizing your suggestion to Jack, not your actual :programming style...From some of your designs I remember seeing, it's :clear that you're a good programmer. And your software's functionality :is marvelous anyway; I just figure someone's gotta throw in the obligatory :comments about modern programming methodologies. Creating large modules :is a sin that some of us (like me) commit sometimes, but we shouldn't :advocate it. Not at all, you give me a chance to explain my philosophy! -Matt
jack@cca.CCA.COM (Jack Orenstein) (05/19/88)
In article <5543@cup.portal.com> doug-merritt@cup.portal.com writes: > >We don't know for *sure* that Jack is one of the Good Guys In White, but >he's innocent until proven guilty. I really am, promise. I attend GOTO Anonymous and haven't used one in, oh, 14 years. > Jack, by all means, *please* stick with >your current habits! Yes, I plan to, although I'd give anything if I could quit biting my toenails. Jack Orenstein This is not a disclaimer
doug-merritt@cup.portal.com (05/19/88)
Matt Dillon writes: >Don't get caught up in the theory.... structured >programming isn't just restrictions in the language... in fact, structured >programming is more personal style than anything else, and language >restrictions can almost be ignored. Definitely agree; a good programmer will break the standard "rules" anytime it is appropriate. Programming is still as much of an art as it is a science. As long as one is well informed about what constitutes good art! The only thing I *really* disapprove of is programmers who don't know what structured programming is, who use the "art" argument to justify unreadable code. And who argue interminably about the wonders of goto's, like those windbags in CACM last year. I use goto's sometimes (gasp!), but I know *why* not to use them in general. Same with global variables. One guy posted something last year in another group telling the world that it was stupid to say that "gotos were harmful" because how else could you write an assembler program??? Sigh...human beings are very prone to arguing with someone's *words*, without the slightest regard for whether or not they understand the *concept* expressed by the words. I'm just rambling here; I'm sure we all agree on the generalities, if not the trivial specifics. [ Answering my apology for sounding critical: ] >Not at all, you give me a chance to explain my philosophy! Welcome. The important thing is for issues to be brought up, not to establish some (probably nonexistent) absolute answer to them. Doug --- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug