These notes are written in chronological order. 

= Development notes =

== Simplifier O(n^2^) ==

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(n^2^) 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 [http://thoughtpolice.stringsandints.com/code/lhc-tests/hello-world/ 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.