Explore whether panics cause a slowdown
In the deep, dark bowels of Coercion.simplifyArgsWorker
, we see this (don't be scared off this ticket yet, I promise!):
go _ _ _ _ _ _ _ = panic
"simplifyArgsWorker wandered into deeper water than usual"
-- This debug information is commented out because leaving it in
-- causes a ~2% increase in allocations in T9872d.
-- That's independent of the analogous case in flatten_args_fast
-- in TcFlatten:
-- each of these causes a 2% increase on its own, so commenting them
-- both out gives a 4% decrease in T9872d.
{-
(vcat [ppr orig_binders,
ppr orig_inner_ki,
ppr (take 10 orig_roles), -- often infinite!
ppr orig_tys])
-}
That is a very curious thing. This comment says that the choice of what to print in a pprPanic
affects GHC's performance, in a non-trivial, measurable way. In this particular case, the orig_binders
and such are otherwise unused in the local function go
. Thus, their inclusion in this panicking case changes the way GHC builds a closure for go
. Is that the cause of the performance change? I'm not sure, but it's a reasonable first place to look.
But this all makes me wonder: are there other places within GHC, not carefully analyzed by @ningning some time ago, that an arbitrary choice of information in a panic changes our runtime behavior?
I thus propose this piece of juicy, low-hanging fruit: Change the behavior of pprPanic
to ignore its second argument (and to inline always), and see if we get performance improvements. If so, track down their locations.
There is some higher-hanging fruit here, too: other Haskell programmers likely use bottoming expressions for errors sometimes, and their performance may also be affected. Maybe the optimizer should warn if a bottoming expression stops an optimization? But then, how would we disable the warning if the programmer wants to accept the regression? What about bottoming expressions that throw exceptions that are caught? It's a hard thing to design.
In any case, let's chase after the low-hanging fruit first. Any takers? This one shouldn't be too hard.