#8173: GHC uses nub -------------------------------------+------------------------------------- Reporter: nh2 | Owner: leroux Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile-time | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonpj): Don't give up so easily :-) Did you look at the amount of heap the compiler ''allocated''? It's easily discoverable (eg use `+RTS -s`, and it's in the nofib logs too, though I don't think `nofib-analyse` looks for it. (You could fix `nofib- analyse` so that it does.) The point is that reducing allocation is almost always good; and it is a FAR more repeatable number than runtime, for which it is hard to measure small differences. My bet is that `ordNub` will be a tiny win in most cases. The other thing is that while using `ordNub` may not benefit typical programs, it may have a dramatic effect on some weird program which happens to produce very long lists for `nub` to digest. Provided using `ordNub` doesn't slow things down for typical programs (use allocation numbers to check) I'm all for using it so that the edge cases don't fall off a cliff. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8173#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler