make-alpha
[Top][All Lists]
Advanced

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

Re: secondary expansion changes


From: Paul Smith
Subject: Re: secondary expansion changes
Date: Fri, 25 Sep 2009 11:25:20 -0400

On Fri, 2009-09-25 at 17:22 +0200, Boris Kolpackov wrote:
> Hi Paul,
> 
> Paul D. Smith <address@hidden> writes:
> 
> > Let me know if you still see the other issue.
> 
> Now everything appears to work properly. I only see a minor speedup
> on my build system: 12.20s vs 12.60s for an up-to-date check and 
> 73.25s vs 74.50s for a rebuild.

Thanks; I wasn't expecting too much of a performance increase.  What I'm
really trying to get to is a memory footprint decrease.  Programs like
glibc which are enormous and the way they generate their makefiles with
tons of duplicated filenames were running into serious memory pressure
just for make to store everything.

I'm not sure I've achieved it though.

> Valgrind, however, shows some leaks/reachables. Here is the summary:
> 
> ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
> malloc/free: in use at exit: 45,441,894 bytes in 549,011 blocks.
> malloc/free: 24,415,525 allocs, 23,866,514 frees, 3,224,363,450 bytes 
> allocated.
> For counts of detected errors, rerun with: -v
> searching for pointers to 549,011 not-freed blocks.
> checked 40,012,808 bytes.
> 
> LEAK SUMMARY:
>    definitely lost: 315,224 bytes in 6,204 blocks.
>      possibly lost: 4 bytes in 1 blocks.
>    still reachable: 45,126,666 bytes in 542,806 blocks.
>         suppressed: 0 bytes in 0 blocks.

Wow.  45M of reachable memory and 3G of turnover is a LOT.  Whew.  Seems
like you have the same sorts of issues as glibc.  I wonder where all
that memory is going... strings?  struct file*?  struct dep*?

> I could show you how to setup my project (it is open-source) so that
> you can test/debug this yourself. Or I can re-run valgrind once you
> fix the leaks based on your tests.

What would be really nice is if you could run with --leak-check=full and
send me the stack traces for the leaks.  Then I could see if they were
the same ones I'm seeing when I run the regression tests.

But, instructions on how to build your environment are welcome as well;
it seems like a worthy test case to be added to my environment.





reply via email to

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