On Wed, 2015-04-15 at 14:35 +0100, David Rothlisberger wrote: > So it seems to me that 3.82 introduced two performance regressions, > one of which was fixed in 4.0 but the other one (during teardown) > remains.
Actually based purely on your numbers and description of the test environment, but not doing any testing myself, my suspicion is that it's the same performance regression but we just weren't able to reduce it back down to zero (yet?). I believe this is caused by the change to pattern rule searches from a "first found" to a "shortest stem" model that Boris added. That model could involve more work in some situations (where the non-stem part of the pattern doesn't help you sort things). The built-in rules have a lot of these types of patterns. I did a fix to solve the worst offender but there is another fix needed, related to "leaking" memory (not really leaking, but not released when it could be); I had an email conversation with Boris about it a while ago: http://lists.gnu.org/archive/html/bug-make/2013-05/msg00103.html However, it could well be something else. You could generate a performance graph and see where make is spending its time during those 15 seconds. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
