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. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
