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