bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU make release candidate 3.99.90 available


From: Boris Kolpackov
Subject: Re: GNU make release candidate 3.99.90 available
Date: Mon, 20 May 2013 11:09:39 -0400
User-agent: Mutt/1.5.18 (2008-05-17)

Hi Paul,

Paul D. Smith <address@hidden> writes:

> There's still a serious regression in the code due to the change in
> pattern rule searching added in 3.82.  In some (not that unusual)
> circumstance GNU make will chew _enormous_ amounts of memory, compared
> to what it used to use in 3.81 and below.
> 
> This is because in the current algorithm, every single time we do an
> implicit rule search and compute possible target and dependency names
> they are all added to the string cache, even if they are deemed to be
> useless and not needed because that implicit rule is not chosen.  In
> cases where there are lots of futile implicit rule searches the string
> cache gets bloated with these useless strings.

Seeing that you haven't fixed it for 4.0, I assume there is no obvious
or easy solution ;-).

I care a lot less about memory than about speed and I believe it is
the same for most other users these days. So maybe we should try to
tune the hash (i.e., the number of buckets) so that lookup doesn't
suffer too much?


> Also I've not seen Debian experimental pick up release candidates like
> this in the past; is that something they do?

I wrote to the maintainer. Let's see what he says.


> Personally I think getting into something like Gentoo may be more
> beneficial since their package management tool is running make quite a
> bit.

Yes, though I would imagine they would be a lot more reluctant to do
this since in their case make runs on the user machine, not on the
build server (where any regressions will be quickly detected and
reported).

Boris

-- 
Boris Kolpackov, Code Synthesis        http://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++      http://codesynthesis.com/products/odb



reply via email to

[Prev in Thread] Current Thread [Next in Thread]