Messages in this thread |  | | From | "Peter T. Breuer" <> | Subject | Re: source dependencies cleanup? | Date | Wed, 4 Dec 1996 00:08:18 +0000 (WET) |
| |
"A month of sundays ago Paul Flinders wrote:" > > > From: Peter T. Breuer <ptb@oboe.it.uc3m.es> > > a) it isn't 8 seconds worth of fast, which is the mkdep time. > > On a 66 Mhz 486 at work "make depend" takes just under 3 minutes.
OK - I used a very very fast machine to get that figure (and fast scsi drives - and 96M of ram).
> Not a major pain as the kernel takes a while to compile on this machine > anyway but I believe (after a quick perusal of the .depend files) that > mkdep > is fast mainly because it skips stuff.
Absolutely wrong (i.e. "that turns out not to be the case" :). It is fast per se and it is helped to be fast by the factthat it does not skip stuff that a cleverer but slower implementation might be able to skip. (gcc is such a beast). It produces a conservative overestimate of the semantically exact dependencies. It is purely a syntactic dependency chaser!
> > b) it requires you to recompile every touched file every time you make > > any update to your system, even if you don't want those files to be > > compiled. Call the time to recompile the dependencies as it goes X. > > Call the time to recompile the object code Y. So the total is X + Y. > > Without doing a lot of work at a sub-file granularity I would be reluctant > *not* to re-compile a file which had been touched as part of an update.
That's wrong. Linus updates the alpha stuff practically every release, and I am not going to recompile _that_! Then there is the m68k stuff, the scsi stuff on a non-scsi machine, all the net drivers that I don't need (I only have one type of card and I use it as a versioned module) plus the sound that I don't use, all the isdn stuff, all the file systems that I don't use etc. etc. etc.
> > Can you suggest a concrete example of when you would touch a file > which you don't want to be re-compiled.
see above. Pick any file not in my architecture.
> > > > c) because of b) (and a)!), it is a lot slower than a makedep follwed > > by a conditional recompilation. Suppose the makedep takes an extra > > 20% of Y, but that after the makedep I only have to actually recompile > > 50% of my files. Then the time to recompile is > > 0.2*Y + 0.5*Y = 0.7*Y > > > > This cannot be worse that X+Y!! You would only have a chance of winning > > out if I had to recompile 80% of my files after an upgrade, which is > > not the case. > > > > In any case, what really happens is that I run mkdep, which takes 0s > > effectively, and then get a slightly worse approximation to the files > > taht I need to recompile. Say I have to recompile 60% instead of 50%. > > Then the total time used is > > 0 + 0.6*Y = 0.6*Y > > The amout of extra time taken by -MD is *very* small. I don't see why
I know. I called it X.
I only assume that it is positive. It could be 0.0001*Y as far as I am concerned and the above shows that it is still too large! You can't beat the math. My point was that 0.7*Y NOT GREATER THAN Y + X.
> any files would be re-compiled without needing to be modulo that fact > that the current scheme may avoid placing commonly changed files > (eg autoconf.h) in the dependancies because most of the kernel includes > them and any edit causes the whole kernel to be re-compiled. However IMO > it is dangerous to omit dependancy information like this and the correct > fix is to split the config #defines into several files.
The last is correct
> Using -MD kives you an accurate picture of the dependancies which > is always up-to-date. mkdep appears to give a partial picture (it doesn't > on brief examination appear to output dependancies for nested files).
That is incorrect.- unless there is a real bug in the mkdep code!
> the dependancies generated by mkdep can also become out of date > (as soon as you add a new header to a source file)
Of course, so what?
> mkdep also ignores #if/#endif which means that I might end up > re-compiling a file un-necessarily because I edit a header which a > source file includes in *some* circumstances but not in the current > configuration.
Yes - that is what I said. It is a conservative (i.e. "safe") over estimate of the semantic dependencies.
> > In my experience > a) "make depend" is still a noticable addition to the compilation time > (although some of this is to do with modules which may still need > to be done & making sure that happens appropriately will need > though)
Use versions.
> b) I can forget to do it. > c) When I really want it to re-compile a small subset of files > after a config change I get half of the kernel re-compiled anyway.
True.
> I think that using -MD would eliminate the non-module part of a) and
Se separate argument about why not in private email.
> eliminate b). It shouldn't affect the "robustness" of the dependancy
True
> tracking (in fact it will probably improve it).
There is no problem with the dependency tracking unless there is a bug. The mkdep dependencies are already over-robust.
I am afraid you cannot beat the math above. You may wish to suggest alternative figures? Your method should produce at least a 30% slowdown according to what I suggested as reasonable. I tried to err on your side - though maybe 0.7 should be 0.75.
--------------------------------------------------------------------- Peter T. Breuer Phd. Ing., Area de Ingenieria Telematica E-mail: ptb@it.uc3m.es Dpto. Ingenieria Tel: +34 1 624 99 47 Universidad Carlos III de Madrid Fax: +34 1 624 94 30/65 Butarque 15, E-28911 Leganes URL: http://www.it.uc3m.es/~ptb Spain
|  |