More conservative SCC tagging for Haskell libraries #45677
Conversation
`all-functions` corresponds to `-fprof-auto` which places an SCC on every binding. It is well known that SCCs hinder GHC from doing its optimization magic and really slows down profiled code to a point where the profiling reports are completely skewed towards things that were completely optimized away in production settings. Concretely this shows up with things like lenses which do not carry runtime overhead when properly simplified. `exported-functions` corresponds to GHCs `-fprof-auto-exported` which doesn't put SCCs on `INLINE`d code and in turn doesn't influence simplification of this basic but important stuff.
|
@ryantm @peti @basvandijk Would like confirmation from at least one of you before going ahead, but this seems to be the right default to me. |
|
@alexbiehl You can change the merge base of your PR by clicking the edit button at the top of the PR near the title. You can also force-push an update to the branch on GitHub to change the PR. |
Interesting, that must be new stuff! |
There was a problem hiding this comment.
@alexbiehl, are there any use-cases where people would actually want profiling for all-functions rather than exported-functions? Or is the latter flag totally and unambiguously better than the former? I wonder because the authors of ghc and Cabal chose all-functions profiling as their default, and I have to assume there are reasons for that choice?
There was a problem hiding this comment.
I think this is the right default.
When the package you're working on is slow you probably want to profile it by entering a nix-shell that brings all the dependencies into scope. Then you probably want to see a detailed profiling report of all the functions in your package so you can spot where time is being spent. So you'll probably use all-functions. However you probably don't care about the inner workings of your dependencies. You just want to see how much time is being spent in the functions you call from your dependencies. So I think for dependencies the proposed exported-functions makes the most sense.
Exactly! |
When you're working on a collection of packages people might want to profile with
I think the reason is what I explained above. It's the proper default for profiling the package you're working on. Probably not for dependencies. We could ask the GHC devs for advise if we're unsure. |
peti
force-pushed
the
haskell-updates
branch
3 times, most recently
from
b2a773d
to
2b2430d
Compare
all-functionscorresponds to-fprof-autowhich places an SCC on every binding. It is well known that SCCs hinder GHC from doing its optimization magic and really slows down profiled code to a point where the profiling reports are completely skewed towards things that were completely optimized away in production settings. Concretely this shows up with things like lenses which do not carry runtime overhead when properly simplified.exported-functionscorresponds to GHCs-fprof-auto-exportedwhich doesn't put SCCs onINLINEd code and in turn doesn't influence simplification of this basic but important stuff.This is even more important as per GHC-8.4 SCCs are also put into unfoldings which make you pay for it at each call site.
Motivation for this change
Things done
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)