[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: glibc build process slowness
From: |
Paul Smith |
Subject: |
Re: glibc build process slowness |
Date: |
Sun, 25 Feb 2007 21:31:03 -0500 |
On Wed, 2007-02-21 at 12:21 -0800, Roland McGrath wrote:
> > the old rule has 1 target (or multiple identical targets)
> > and
> > there exists a target in the new rule the same as the old rule's target
> >
> > See attached makefile which demonstrates this. Is that the correct
> > behaviour? It seems like it would make more sense to compare the
> > target lists for equality.
>
> I think it should match any rule whose target list is a subset of the new
> rule's list, without regard to order.
I agree this seems like the correct behavior. I worry that it's too
inefficient. It could be made much more efficient, though, if we were
allowed to sort the target patterns. Although obviously we can't sort
the prerequisite patterns, and we'll still need to match those.
In theory this should be fine, since the order in which they're
specified shouldn't make any difference. In practice, though, make
seems to have behavior which depends on the order: not all the targets
are treated equally unfortunately. There is at least one bug filed
against make on this point.
There is one other efficiency which will be available soon: to solve
another bug filed against GNU make on behalf of gcc (make uses too much
memory) I'm finishing up a major change to use the string cache for all
filenames in make. Once that's done, we can replace many of the
strcmp's with simple pointer comparisons.
--
-------------------------------------------------------------------------------
Paul D. Smith <address@hidden> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
- glibc build process slowness, Mark Seaborn, 2007/02/21
- Re: glibc build process slowness, Roland McGrath, 2007/02/21
- Re: glibc build process slowness,
Paul Smith <=
- [PATCH 0/5] Improve performance of rule handling, Mark Seaborn, 2007/02/25
- [PATCH 3/5] Refactor: Use a doubly-linked list of rules instead of a singly-linked list, Mark Seaborn, 2007/02/25
- [PATCH 1/5] Refactor: Move rule comparisons into separate functions, Mark Seaborn, 2007/02/25
- [PATCH 2/5] Clean up count_implicit_rule_limits(), Mark Seaborn, 2007/02/25
- [PATCH 4/5] Record rule targets in a hash table, Mark Seaborn, 2007/02/25
- [PATCH 5/5] Hook up hash table: use for searching for rules to replace, Mark Seaborn, 2007/02/25
- Re: glibc build process slowness, Paul Smith, 2007/02/25