Improving cost center reports to show residency?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Improving cost center reports to show residency?

Ömer Sinan Ağacan
One thing that we can't currently see in cost center reports is the residency
and because of that cost centers can't be used for fixing memory leaks or
reducing max. memory residency. For example, I can have a function that returns
an `Int` but allocates lots of intermediate data on the way. In the reports I
see this function as allocates a lot, but it has no effect on my program's
residency (especially if it runs fast).

So I'm thinking of somehow using cost centers for reasoning about memory
residency. One idea is to print a summary after every major GC, by doing another
pass on the whole heap and recording attributions. This can be used for plotting
live data of cost centers over time. (like hp2ps but for cost centers)

Another idea is to add "residency" column in the profiling reports. Not sure how
to update this column in runtime though.

The main use case for me is fixing T1969, but of course this is a very general
solution.

Does anyone have any other ideas?
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Improving cost center reports to show residency?

Edward Z. Yang
Hello Omer,

I don't quite understand; is +RTS -hc what you want?  That will output
a heap profile per cost center, which will give you residency.  Is the
problem that you need a heap profile every minor GC rather than major
GC (e.g. something like https://ghc.haskell.org/trac/ghc/ticket/8504 ?)

Edward

Excerpts from Ömer Sinan Ağacan's message of 2016-08-08 11:28:48 +0000:

> One thing that we can't currently see in cost center reports is the residency
> and because of that cost centers can't be used for fixing memory leaks or
> reducing max. memory residency. For example, I can have a function that returns
> an `Int` but allocates lots of intermediate data on the way. In the reports I
> see this function as allocates a lot, but it has no effect on my program's
> residency (especially if it runs fast).
>
> So I'm thinking of somehow using cost centers for reasoning about memory
> residency. One idea is to print a summary after every major GC, by doing another
> pass on the whole heap and recording attributions. This can be used for plotting
> live data of cost centers over time. (like hp2ps but for cost centers)
>
> Another idea is to add "residency" column in the profiling reports. Not sure how
> to update this column in runtime though.
>
> The main use case for me is fixing T1969, but of course this is a very general
> solution.
>
> Does anyone have any other ideas?
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs