2017-09-26 18:35 GMT+02:00 Ben Gamari <b...@smart-cactus.org>: > While it's not a bad idea, I think it's easy to drown in information. Of > course, it's also fairly easy to hide information that we don't care > about, so perhaps this is worth doing regardless. >
The point is: You don't know in advance which of the many performance characteristics "perf" spits out is relevant. If e.g. you see a regression in runtime although you really didn't expect one (tiny RTS change etc.), a quick look at the diffs of all perf values can often give a hint (e.g. branch prediction was screwed up by different code layout etc.). So I think it's best to collect all data, but make the user-relevant data (runtime, code size) more prominent than the technical/internal data (cache hit ratio, branch prediction hit ratio, etc.), which is for analysis only. Although the latter is a cause for the former, from a compiler user's perspective it's irrelevant. So there is no actual risk in drowning in data, because you primarily care only for a small subset of it.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
