Re: GNU make release candidate 3.99.90 available

[Paul Smith]

On Mon, 2013-05-20 at 11:09 -0400, Boris Kolpackov wrote:
> > 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've poked at it a few times for just a couple of minutes but nothing
trivial occurred to me.  I was hoping you'd look at it :-p :-).

I don't think it's SO difficult to fix but it can be fiddly--this entire
area is a bit fiddly.

> 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?

The complaint I got was that GNU make 3.82 was using 100's of MB of RAM
more than it used to and this was the problem, not the lookup time.  I'm
not really jazzed about adding a workaround like this; the strcache is
intended only for truly static strings that should exist for the
lifetime of the process.  It shouldn't be abused that way IMO.