Bugs item #635718, was opened at 2002-11-08 23:43 Message generated for change (Comment added) made by ajk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=635718&group_id=8032
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: 5.04 Status: Closed Resolution: Rejected Priority: 6 Submitted By: Antti-Juhani Kaijanaho (ajk) Assigned to: Simon Peyton Jones (simonpj) Summary: Bad space behaviour with huge input file Initial Comment: The attached files (actually, just UnicodeData.hs but the other file is imported by it) trigger very bad space and time behaviour in ghc during compilation. One attempt went up to 500 MB of virtual memory (256 physical available) on my i386 machine. The compilation ran for more than an hour until killed (stuck in the rename phase). I had another version (available on request) of this that has all the data in a string, compiled into an object file using gcc (in no time!), accessed using FFI and then using read made into a real data structure. The program, looking up one entry in the resulting FiniteMap, has a memory hit of approximately 130 MB and runs in one minute (which, while still too much, is bearable). So it seems there is lots to improve in the compiler in this case (we are essentially talking about the same process taking way too much time and memory when done by the compiler, compared to the program itself doing it - and even then the memory requirement is outrageous). Even some sort of special-casing pragma that allows me to ask for lighter treatment of pure data would be good (and a way to statically initialize a FiniteMap...) I'm sorry but I do not have any simpler input files to offer. ---------------------------------------------------------------------- >Comment By: Antti-Juhani Kaijanaho (ajk) Date: 2005-08-11 10:54 Message: Logged In: YES user_id=14329 Of course it is a huge file. That's the whole point of this bug report :) And as to it being syntactically invalid, and having type errors - I believe this is all the more reason to fix this. How am I supposed to fix these issues if the compiler does not give me a diagnostic? I can appreciate that typechecking can have inherently bad space/time behaviour for pathetic cases, but if we are talking about a syntactically invalid file, the compiler should not even get to typechecking, now should it. Parsing, however, is a well-understood part of computer science and has no such nasty surprises. ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2005-08-10 18:03 Message: Logged In: YES user_id=48280 This source file is simply huge (6M) and contains a single large nested non-constant expression. Also, it isn't syntactically correct, and even when the syntax errors are fixed it has type errors. I'm going to close this bug. Feel free to submit more examples of code that GHC takes too long to compile, but there's not much we can do with this one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=635718&group_id=8032 _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
