[Hackage] #200: Allow more convenient use of ghc profiling
options -auto and -auto-all
Hackage
trac at galois.com
Fri Jul 25 09:06:00 EDT 2008
#200: Allow more convenient use of ghc profiling options -auto and -auto-all
----------------------------+-----------------------------------------------
Reporter: guest | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Cabal-1.6
Component: Cabal library | Version:
Severity: normal | Resolution:
Keywords: | Difficulty: easy (<4 hours)
Ghcversion: 6.8.2 | Platform:
----------------------------+-----------------------------------------------
Comment (by dolio):
It may be that having annotations on all the libraries one uses is too
much information. However, I'd argue that annotations on library calls
isn't useful merely for profiling said libraries.
So, my program is slow, and it spends most of the time in function f.
f x = ... includes calls to some libraries ...
What is slow about f? Is it doing some of its own stuff that takes
time/memory, or if we unfolded one level, would we find that 90% of f's
work is done in the library calls it makes? Now, at some level, I suppose
you can get carried away with that (f doesn't do any work, it's all GHC
primops :)), but I think that a bit of such information can be useful, to
tell me that I need to swap in a different data structure, or contact the
library's maintainer and see if anything can be done to speed it up. Maybe
you can do some of that with manual SCC annotations, but I've had trouble
getting those to work well for me.
At least, it seems to me that there are situations where libraries aren't
simply a profiling black hole would be useful when *not* profiling that
particular library (even if only to tell you that that library needs to be
profiled :)). See the somewhat recent BLAS optimization question on
haskell-cafe for a potential example (is it his use of lists and non-fused
operations? Is BLAS itself slow? etc.).
It'd be nice if there were a way to turn -auto-all on and off for
libraries when compiling an application that uses those libraries. Of
course, I don't suspect that's an option at the moment (I suppose you
could build two sets of profiling files for each library, and have some
way of selecting them, but I imagine that'd be hairy).
Anyhow, just my 2 cents on the issue.
--
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/200#comment:8>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects
More information about the cabal-devel
mailing list