Обсуждение: Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane <tgl@postgresql.org> 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
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane <tgl@postgresql.org> 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
On Tue, Jan 5, 2010 at 3:42 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane <tgl@postgresql.org> 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
On Mon, Jan 4, 2010 at 10:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane <tgl@postgresql.org> 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
On Mon, Jan 4, 2010 at 10:53 PM, Greg Stark <gsstark@mit.edu> wrote: > On Tue, Jan 5, 2010 at 3:42 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane <tgl@postgresql.org> 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: Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
От
Alvaro Herrera
Дата:
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
Robert Haas <robertmhaas@gmail.com> 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
On Mon, Jan 4, 2010 at 11:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> 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
Re: Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
От
Peter Eisentraut
Дата:
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.