#1607: seq can make code slower
---------------------------------+------------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: low | Milestone: 7.0.1
Component: Compiler | Version: 6.6.1
Keywords: | Testcase:
Blockedby: | Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
---------------------------------+------------------------------------------
Changes (by michalt):
* cc: michal.terep...@… (added)
* failure: => Runtime performance bug
Comment:
I've just tried the attached tests and I'm really not sure what to think
about
the results:
{{{
Lazy tests
writeTime = 928
pushTime = 929
Strict tests
writeTime = 915
pushTime = 959
Lazy tests
writeTime = 931
pushTime = 928
Strict tests
writeTime = 918
pushTime = 961
}}}
So `genWriteFast` is a little bit faster with the strict annotations,
which
would be a counter-example to your hypothesis. But at the same time the
`genPush` is slower with strict data type, which would agree with your
initial
idea. And this is because `seq` not applied to both children:
{{{
putNL (N ll le lr) e r = let l' = putN ll le lr
in l' `seq` N l' e r
}}}
Notice that only `l'` is forced to evaluate. Whereas in case of strict
`AVL`
data type when we have
{{{
putNL (N ll le lr) e r = N (putN ll le lr) e r
}}}
I guess both `putN ...` and `r` be evaluated (i.e. as you've mentioned in
the
description - `N` doesn't know that `r` is already evaluated). Adding
additional
`seq` in the "Lazy" version:
{{{
putNL (N ll le lr) e r = let l' = putN ll le lr
in r `seq` l' `seq` N l' e r
}}}
makes the running times for `genPush` pretty much the same in both cases.
Anyway, there is also some good news - with current HEAD it seems that the
differences are nowhere near 15% and the sizes of binaries are the almost
the
same. :)
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1607#comment:8>
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
