#5536: IO performance regression in 7.2 vs 7.0
---------------------------------+------------------------------------------
Reporter: simonmar | Owner: batterseapower
Type: bug | Status: new
Priority: high | Milestone: 7.4.1
Component: libraries/base | Version: 7.2.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by simonmar):
Oh, I hadn't realised the Core looked like that. We can do much better!
The code generated for this:
{{{
case (case x <# y of True -> C# ...; False -> C# ...) of c {
loop (c:cs) x
}
}}}
makes a case continuation for the outer case. Each branch of the inner
case builds a `C#`, and then jumps directly to the continuation. That's
not bad, but we don't need a continuation at all. We'd much rather
generate
{{{
case (case x <# y of True -> e1; False -> e2) of z {
loop (C# z : cs) x
}}}
So this would all be within a single function, no continuations.
But I don't see how to get that without writing it explicitly - that is,
making `desurrogatifyRoundtripChar` work with `Char#`. GHC would have to
notice that all the branches of the inner case return an explicit `C#`
constructor. Simon, do we have anything that does that?
I did manage to get GHC to do the case-of-case transformation though,
which results in better code. By changing `unpack` to look like this:
{{{
case desurrogatifyRoundtripCharacter c of { C# c# ->
unpackRB (C# c#:acc) (i-1) }
}}}
GHC now does case-of-case, duplicating the final tail call in each branch.
This might be the best we can do here in fact, since speed is much more
important than saving a bit of code size. It's bad that this gives
different code than just using `seq` or bang-patterns, though.
I'll validate and commit the change (with a comment).
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5536#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
