Re: Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
Re: Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
От:
Peter Eisentraut <peter_e@gmx.net>
Дата:
On mån, 2010-01-04 at 22:54 -0500, Robert Haas wrote: > I think you're dismissing the idea too cavalierly. If A generates B, > A is inevitably changed frequently, but the changes to A affect B only > rarely, this is a good trick. If that is the case, you might want to consider splitting up A or refactoring B so you don't have so many useless dependencies.
Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
От:
Tom Lane <tgl@sss.pgh.pa.us>
Дата:
Robert Haas writes: > On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane wrote: >> Log Message: >> ----------- >> Remove too-smart-for-its-own-good optimization of not overwriting the output >> files when they haven't changed. �This confuses make because the build fails >> to update the file timestamps, and so it keeps on doing the action over again. > This doesn't seem like a good idea. The original code was a bad idea, written by someone who was a self-acknowledged non expert on make. The way that you avoid unnecessary recompilations is by not changing the input files, not by breaking the file timestamp relationships that make depends on to work sanely. regards, tom lane
Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
От:
Tom Lane <tgl@sss.pgh.pa.us>
Дата:
Robert Haas writes: > I think you're dismissing the idea too cavalierly. If A generates B, > A is inevitably changed frequently, but the changes to A affect B only > rarely, this is a good trick. The only output file that is unlikely to change is schemapg.h, which is depended on by exactly one .c file. It's a waste of time to try to optimize this at all ... regards, tom lane
Re: Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
От:
Alvaro Herrera <alvherre@commandprompt.com>
Дата:
Greg Stark escribió: > I think there's a trick to cover this case but I don't recall what it is. > > Does generating a stamp file help? If you had a rule saying to trigger > generating the output files because the stamp file is out of date > which might or might not touch the .h file which would trigger more > files to be rebuilt then everything should work.... except I fear this > leads us back to the "make rule which generates two files" problem... That doesn't work because the files being generated are headers, and thus they are detected as dependent files automatically by gcc's -MMD feature (--enable-depend) Maybe there's a way to make it work but this is not it. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
От:
Greg Stark <gsstark@mit.edu>
Дата:
On Tue, Jan 5, 2010 at 3:42 AM, Robert Haas wrote: > On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane wrote: >> Log Message: >> ----------- >> Remove too-smart-for-its-own-good optimization of not overwriting the output >> files when they haven't changed. This confuses make because the build fails >> to update the file timestamps, and so it keeps on doing the action over again. > > This doesn't seem like a good idea. Not rebuilding the output files > also saves recompiling the things that depend on them. For the BKI > files thast doesn't matter much, but for schemapg.h it might be > significant. Certainly, if we move to generating more header files > this way, it WILL be significant. If running the script is cheap (and > it should be), it's better to take that hit rather than recompiling a > whole mess of .c files unnecessarily. I think there's a trick to cover this case but I don't recall what it is. Does generating a stamp file help? If you had a rule saying to trigger generating the output files because the stamp file is out of date which might or might not touch the .h file which would trigger more files to be rebuilt then everything should work.... except I fear this leads us back to the "make rule which generates two files" problem... -- greg
Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
От:
Robert Haas <robertmhaas@gmail.com>
Дата:
On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane wrote: > Log Message: > ----------- > Remove too-smart-for-its-own-good optimization of not overwriting the output > files when they haven't changed. This confuses make because the build fails > to update the file timestamps, and so it keeps on doing the action over again. This doesn't seem like a good idea. Not rebuilding the output files also saves recompiling the things that depend on them. For the BKI files thast doesn't matter much, but for schemapg.h it might be significant. Certainly, if we move to generating more header files this way, it WILL be significant. If running the script is cheap (and it should be), it's better to take that hit rather than recompiling a whole mess of .c files unnecessarily. ...Robert
Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
От:
Robert Haas <robertmhaas@gmail.com>
Дата:
On Mon, Jan 4, 2010 at 10:51 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane wrote: >>> Log Message: >>> ----------- >>> Remove too-smart-for-its-own-good optimization of not overwriting the output >>> files when they haven't changed. This confuses make because the build fails >>> to update the file timestamps, and so it keeps on doing the action over again. > >> This doesn't seem like a good idea. > > The original code was a bad idea, written by someone who was a > self-acknowledged non expert on make. The way that you avoid > unnecessary recompilations is by not changing the input files, > not by breaking the file timestamp relationships that make depends > on to work sanely. I think you're dismissing the idea too cavalierly. If A generates B, A is inevitably changed frequently, but the changes to A affect B only rarely, this is a good trick. ...Robert
Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
От:
Robert Haas <robertmhaas@gmail.com>
Дата:
On Mon, Jan 4, 2010 at 10:53 PM, Greg Stark wrote: > On Tue, Jan 5, 2010 at 3:42 AM, Robert Haas wrote: >> On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane wrote: >>> Log Message: >>> ----------- >>> Remove too-smart-for-its-own-good optimization of not overwriting the output >>> files when they haven't changed. This confuses make because the build fails >>> to update the file timestamps, and so it keeps on doing the action over again. >> >> This doesn't seem like a good idea. Not rebuilding the output files >> also saves recompiling the things that depend on them. For the BKI >> files thast doesn't matter much, but for schemapg.h it might be >> significant. Certainly, if we move to generating more header files >> this way, it WILL be significant. If running the script is cheap (and >> it should be), it's better to take that hit rather than recompiling a >> whole mess of .c files unnecessarily. > > > I think there's a trick to cover this case but I don't recall what it is. > > Does generating a stamp file help? If you had a rule saying to trigger > generating the output files because the stamp file is out of date > which might or might not touch the .h file which would trigger more > files to be rebuilt then everything should work.... except I fear this > leads us back to the "make rule which generates two files" problem... The trick being used here was essentially the same as the stamp-file trick. But it may not be worth worrying about for the moment since not too many things depend on schemapg.h. I fear it will become an obstacle to further improvements, however. ...Robert
Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
От:
Robert Haas <robertmhaas@gmail.com>
Дата:
On Mon, Jan 4, 2010 at 11:03 PM, Tom Lane wrote: > Robert Haas writes: >> I think you're dismissing the idea too cavalierly. If A generates B, >> A is inevitably changed frequently, but the changes to A affect B only >> rarely, this is a good trick. > > The only output file that is unlikely to change is schemapg.h, which is > depended on by exactly one .c file. It's a waste of time to try to > optimize this at all ... OK, fair enough. ...Robert
