|Version 2 (modified by thoughtpolice, 5 years ago)|
These notes are written in chronological order.
Deriving Show for System.Local.TimeLocal fails with a stack overflow.
We hit a performance bug when deriving Show. With one field it takes three seconds, with two it takes seven seconds, and with three it blows the stack after more than a minute.
It appears that function composition requires O(n2) compilation time.
JHC was too eager at renaming idents after inlining. It also never dropped unused ids. This resulting in the book-keeping of several tens of thousands of ids.
JHC used a very naive method of getting unique ids. It involved trying every possible id from 1 to infinity. This is obviously O(n) when it should be O(1).
The problem has been fixed in lhc. The package old-locale now compiles straight off hackage, and building base showed a speed-up of 17.3%
Too much garbage
When running lhc, about 50% of the run-time is spent on garbage collection. This is completely unjustified. We shouldn't be creating and discarding so much information.
2008-11-23 (thoughtpolice): after doing some profiling work, it turns out that we use a lot of memory and time in E.Binary (on get routines) if we look at the cost centres, and by looking at constructor/type information from the profiler, it looks like we do use a lot of memory on lazy tuples and the S datatype which is used in the lambda lifter/CPR.
In what ways can we tackle these memory leaks? We may be able to use the binary-strict package, but there's no guarantee it will lower memory use/increase speed.
Replacing the Id type with an ADT resulting in a slowdown of 12%. This is acceptable (for now).
Blah, I must have made some mistake doing the translation. Reverting to the simple Id type.