Dear list, I was working on https://ghc.haskell.org/trac/ghc/ticket/10788 (performance regressions involving minimum), and I found it quite unsatisfactory to twiddle with individual functions, based on individual test cases, this way. Of course I can improve things for a combination of functions and testcase, but if so, shouldn’t I be improving others as well? What about other test cases – will they regress? How should I balance the goals of speed, code size and simplicity? This feels more like a random walk rather than hill-climbing, let alone a disciplined approach to the problem. Can we have a disciplined approach? I.e. a set of guidelines that work well in general, can be documented and communicated to the user, and that we can follow in such cases? Here is a rough draft, more to show what I am aiming for, rather than a finished work: * Functions that can take part in list fusion have RULES to rewrite them in terms of foldr/build, but also RULES to write them back. Phase control ensures that this is done by phase 0, and the following applies to phase 0. * Recursive non-polymorphic non-higher-order functions are not marked as INLINE (and thus not inlineable, beside possibly the wrapper of a worker-wrapper split). * Recursive polymorphic non-higher-order functions are marked as INLINEABLE, and SPECIALIZE pragmas are given for common cases. (Example: minimum, maximum). * Recursive higher-order functions are implemented with a local recursive function, to allow for inlining (foldl, foldr, maximumBy), at least if there is a chance of further optimizations due to strictness analysis. Given such a guideline, I would then know what to do with such a ticket, instead of stabbing in the dark. It might mean that we would have to tell a user who observes suboptimal performance in one case that this is unavoidable (we cannot optimize for everyone) and possibly explain how to work around the issue. Or we might find that the discipline could be improved, but then the improvement should be applied to all functions. Thoughts? Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org