There is definitely a performance bug somewhere in GHC, and we're
collecting cases that show it up. It'd be ideal if you, or someone
else, could snip out a standalone module or two that demonstrates the
problem, rather than all of WASH. If not, we'll try to tackle it
directly.
Simon
| -----Original Message-----
| From: glasgow-haskell-users-bounces@haskell.org
[mailto:glasgow-haskell-users-
| bounces@haskell.org] On Behalf Of John Goerzen
| Sent: 06 June 2005 21:21
| To: glasgow-haskell-users@haskell.org
| Subject: Re: GHC hang
|
| On 2005-06-06, Simon Peyton-Jones
On Tue, 2005-06-07 at 10:52 +0100, Simon Peyton-Jones wrote:
There is definitely a performance bug somewhere in GHC, and we're collecting cases that show it up. It'd be ideal if you, or someone else, could snip out a standalone module or two that demonstrates the problem, rather than all of WASH. If not, we'll try to tackle it directly.
I've got a happy grammar that takes ghc many minutes and hundreds of Mb to typecheck if I leave off the types for all the productions. If I add types for all the productions it's pretty quick and uses very little memory. But I think this is a known issue (it's mentioned in the happy manual) and not the one you were interested in. Am I right? I was just suprised that it is such a dramatic effect! Duncan
On Tue, Jun 07, 2005 at 10:52:12AM +0100, Simon Peyton-Jones wrote:
There is definitely a performance bug somewhere in GHC, and we're collecting cases that show it up. It'd be ideal if you, or someone else, could snip out a standalone module or two that demonstrates the problem, rather than all of WASH. If not, we'll try to tackle it directly.
Here's where I've seen it: WASH HTMLMonad98 (only depends on one other module) WASH HTMLPrelude98 One of the RFC modules in http://cryp.to/hsemail/, but I forget which one It seems that Parsec code, in general, tends to be slow. -- John
participants (3)
-
Duncan Coutts -
John Goerzen -
Simon Peyton-Jones