#10005: Operations on string literals won't be inlined -------------------------------------+------------------------------------- Reporter: fread2281 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): We wanted literal strings to be good producers, so that `map f "wubble"` would work without generating and then pattern matching on the intermediate string. That is why `"foo"` desugars to {{{ build (unpackFoldrCString# "foo"#) }}} This seems reasonable. Now `head` has this rule: {{{ "head/build" forall (g::forall b.(a->b->b)->b->b) . head (build g) = g (\x _ -> x) badHead }}} (goal: make `head` a good consumer), and that rule fires on `head "foo"` giving the result in comment:1. It is a bit stupid, but I don't see an immediate way out. One alternative would be to kill off the `head/build` rule. After all, most `fold/build` rules save an entire traversal of the list whereas this one saves the allocation and pattern match on a single cons cell. So the win is much smaller. If someone would like to * Switch off RULES `head/build` and `head/augment` (in `GHC.List`) * See what performance difference, if any, happens in `nofib` * Track down any increases that would be a splendid thing. More radical would be to nuke the entire `unpackFoldrCString` ideaa, so that literal strings are not good producers. But I think that would probably be bad. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10005#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler