Bad space behaviour with huge input file
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.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information