Static data and RULES
ben at well-typed.com
Fri Feb 17 15:21:37 UTC 2017
Simon Peyton Jones <simonpj at microsoft.com> writes:
> PS: before we go to some effort to optimise X, can we
I briefly characterized this earlier this week. For a module exporting
lots of static data of roughly the same type as TypeRep (e.g.
data T = T Addr# Int# Int), the cost scales essentially linearly in the
number of static bindings, so I don't think there's any easy
non-linearity to fix here.
However, compiler allocations roughly double when moving from -O0 to -O1
(from roughly 300 kB / binding to roughly 600 kB / binding). Allocations
hardly increase any further with -O2. I just checked now and the C--
Admittedly, allocations only doubling isn't so bad given how much it
costs to optimize non-trivial code (e.g. an Ord instance). Unfortunately
I didn't quantify this effect in my investigation earlier in the week.
I'll do so now:
With -O0 deriving even one set of simple Eq and Ord instances increases
allocations while compiling even the 10000 static binding program by
nearly 30%. This suggests that, compared to "real" code, simplification of
the static bindings is relatively cheap. Indeed I should have checked this
However, this is interesting as when I look back on my measurements of
the comparing pre- and post-Typeable compilers on `lens`, I see that the
largest changes in compiler allocations (as reported by -v) tend to be
in demand analysis, called arity analysis, and the specialiser. This
clearly needs further investigation.
I've put the testcase here  if anyone wants to play with it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: not available
More information about the ghc-devs