Agreed. Cabal should warn.
On Sep 21, 2014 8:13 PM, "Oliver Charles"
Hi all,
I'd like to start a conversation around the ghc-prof-options option that can be used in Cabal-ized libraries. As you may know, this option specifies extra GHC options that are used when --enable-library-profiling is enabled. This is very convenient for local development, but I argue that it can be counter-productive for releases onto Hackage.
To provide an example, I'm currently working on a little game engine that uses JuicyPixels to load images. I have a problem in my code that needs optimizing, but the current state of things results in profiles that are very difficult to work with. JuicyPixels specifies -auto-all in its cabal file, which means I have no alternative but to profile JuicyPixels code. In this scenario, the bottleneck is actually within my FRP game loop and nothing to do with image loading! As a result, the profiles are fairly useless to me.
Roman Cheplyaka also points out that by doing this, profiles are skewed - -auto-all is not free, so we actually pay in runtime performance every time a library does this.
I would like to hear from others if we should consider managing this option a little more. My personal feeling is that this flag shouldn't be used unless in local development, so guarded by an off-by-default build flag. I think cabal should also warn authors who are using this flag, and encourage them to place a guard around this option.
Thoughts? - ocharles
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe