[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