GHC Trac Home
GHC Git Repos
Report a bug
Mailing Lists & IRC
The GHC Team
GHC Status Info
Tickets I Created
Patches for review
New Feature Req
side by side
lines around each change
Show the changes in full context
White space changes
Oct 2, 2010 5:40:24 PM (
The goal of this project is to have GHC guide the user to better performance, by warning of coding patterns that won't yield good performance.
== Approach ==
Users have trouble understanding how strictness analysis works, how demand analysis works, when and why things are specialized, inlined or unboxed. Our goal is for the compiler to tell them when such things happen, in order to guide them to better code.
== Stage 1: Performance Lint ==
=== Strictness Warnings ===
Users often feel a shotgun approach to strictness is the only way to fix performance or space problems. Due to difficulties reasoning about demand, a scattergun approach -- dropping bang patterns everywhere -- is used to squash laziness issues. This is usually unnecessary, and may make programs slower, than placing the getting the strictness precisely right.
'''The compiler should warn about unnecessary uses of bang patterns or seq.'''
=== Heuristics for "Probably a Performance Bug" ===
* Int, Word, Int*, Word*
* Double, Float
should almost always be unboxed in users' code. It is exceedingly rare for such values to be necessarily lazy for correctness. However, due to insufficient strictness, such types are often inferred as lazy, and consequently not unboxed.
We can improve users' code by warning of any boxed types as arguments, or in data structures, for these types. Particularly accumulating parameters, or fields in record types. Additionally, if they are strict, but not unboxed, that should also be a warning.
=== Other heuristics ===
* Warning any use of >>= that doesn't inline
* Warn about lazy state monads
* Warn about lazy tuples
== Output format ==
We could emit warnings about line / col number of values that "probably should be strict" or "have unnecessary bang patterns".
A more advanced option would be to reuse -fhpc to emit colorized source.
== Assertions ==
Once we can spot problems, the user could assert, via ANNOTATIONs, that particular properties must hold. These could trigger -Werrors.
== Results ==
Results for quality of the warnings can be measured:
* Apply -fwarn-performance to a program
* Do what it says
* Measure the speedup.
== Implementation ==
Add a -fwarn-performance flag that does two things:
* unnec. bang patterns/seq after strictness analysis
* uses a library of heuristics (programmable?) to lint-check core.
* The pass would be a core-to-warnings pass.