3 questions regarding profiling in ghc

[Daniil Elovkov]

John Dorsey wrote:
> Daniil,
> 
> While you're waiting for an answer from a GHC internals expert, here's my
> experience as a fellow user.
> 
>> 1) Can I profile my program if I don't have all the libraries it depends  
>> on compiled with profiling?
> 
> I don't know how to do that, and I don't know how to automatically reinstall
> all dependencies of my project with profiling enabled.  I recently went
> through reinstalling said dependencies as I found them, iteratively.  I
> could have blown away and reinstalled GHC instead, and saved time.
> 
> To prevent a recurrence, I now have this in my ~/.cabal/config :
> 
> library-vanilla: True
> library-profiling: True
> 
> This should install both normal and profiling versions of every library that
> I install with cabal from here out.  It's a little slower when installing
> new library packages, but it doesn't come up often enough to bother me.
> There may be some pain when I get around to bootstrapping GHC 6.12, if
> it doesn't install profiling builds of its bundled libs.
> 
>> Moreover, as far as I could tell functions from those packages didn't  
>> appear in the call graph after +RTS -p profiling.
> 
> Did you use "-auto-all", to automatically create cost centers for all
> top-level functions?  I find that I get very verbose cost info for
> definitions under imported libraries.

Yeah, I've got it. Modules in packages were done by cabal configure -p. 
That probably doesn't imply -auto-all.

> 
>> 2) Can I exclude a function from profiling? That probably means not  
>> assigning a cost centre to it.
> 
> If "-auto-all" doesn't please you, you can manually define your cost centers
> in your code, leaving out the ones you don't care about.  But unless I'm
> mistaken, that doesn't exclude those costs, but rather includes them in the
> calling cost center.  So it may not be what you're asking for.
> 
>> Typical case, I think. Database connect function is rather heavyweight  
>> (regarding time) compared to the rest of the code, and it takes up to  
>> 98% of time. So the rest of the picture is less informative than it  
>> could be.
> 
> It's your business, but in that case why would you care about the (time)
> profile of the rest of the code?  I wouldn't spend ten seconds
> time-optimizing anything but that hot spot.  If it can't be improved, you're
> done.

Makes sense.

Well, in other circumstances that connect function may either take a lot 
less time or not run at all. Of course the answer here could be: so 
profile the program in _that_ case as well.

Ok, I was just wondering :)

> To be clear, I'm assuming you're talking about 98% of CPU time, not wall
> time; I don't think the profiler reports wall time, except maybe in the
> summary.
> 
>> 3) Isn't it possible to have -p profiling data of the interrupted  
>> (ctrl-c) program?
> 
> When I ctrl-c out of my program, I get a nice <program>.prof file in the
> directory where it's running.  If you're not getting that, the difference
> could be OS environment (I'm developing on Linux), or it could be that I'm
> using happstack and calling a routine that catches the ctrl-c then exits
> cleanly.  It's Happstack.State.waitForTermination; you can probably distill
> enough from it to get the same effect.
> 
> http://hackage.haskell.org/packages/archive/happstack-state/0.3.4/doc/html/src/Happstack-State-Control.html#waitForTermination
> 
> (Pardon the long link.)  My main routine spins off threads to do all the
> work, and the main thread waits on waitForTermination then shuts down.
> 

Of course, catching ctrl-c and exiting normally alone is definitely 
sufficient to get the .prof file, because it's just no different than 
simply exiting.

Thanks John, Simon.


--
Daniil Elovkov