Bugs item #635718, was opened at 2002-11-08 23:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=635718&group_id=8032

Category: Compiler
Group: 5.04
Status: Open
Resolution: None
Priority: 5
Submitted By: Antti-Juhani Kaijanaho (ajk)
Assigned to: Nobody/Anonymous (nobody)
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.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=635718&group_id=8032
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to