These notes are written in chronological order.

Development notes

Simplifier O(n2)

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.

Id Type

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.