Ticket #2002 (closed bug: wontfix)
problems with very large (list) literals
|Reported by:||Isaac Dupree||Owned by:||simonmar|
|Operating System:||Linux||Architecture:||x86_64 (amd64)|
|Type of failure:||Compile-time performance bug||Difficulty:||Unknown|
|Test Case:||Blocked By:|
I could have sworn parts of this had been reported before, but I can't find it, and further investigating makes it look more complicated.
A file with about 100000 elements in a literal list (see attached "longlist.hs") causes a stack overflow in ghc-6.8.2 after 20 seconds. For comparison, ghc-6.6.1 took a few minutes on my fast machine before I got bored and quit. ghc-6.8.2 +RTS -K300M succeeded in the span of a minute.
So the only way I know to reproduce it is: by running alex (not alex -g) on some of GHC's .x files (cmm/CmmLex, parser/Lexer) and compiling them as part of the GHC build process. Alex has some bugs without -g that I'll upgrade mine and/or send darcs patches later, and my build process is quite hacky, so I don't have a good reproducible case right now, but I'll try to make one later. This caused ghc not to terminate in a reasonable amount of time, even without -O0, and to use a lot of memory. When I replaced the commas in the lists with ":" and the end with ": " to make a non-sugared list, ghc still didn't terminate very soon, and it used a lot more memory, so it was eventually killed by the OOM-killer :-) This is actually affecting my ghc-hacking work a little, so I would be pleased to see it fixed... tell if there's something particular I could say that would help tracking this down.