Changing the order of arguments improves performance in the common case.
Changing the order of arguments improves performance in the common
case.

Specifically, the second (of three) intraprocedural dead code
elimination passes on the celestial mechanics example was taking 20s
on 20k pairs input before the change, and takes 0.34s now.  This
produces about 12% speedup in the overall compilation time of the
celestial mechanics example.

Why does such a small change make such a big difference?  This
question is intimately related to the question of why it was
specifically the second (but not the first or the third) pass of
intraprocedural dead code elimination that was taking so long in the
first place.  The reason is that this pass was occurring after SRA but
before interprocedural dead code elimination.  At this point the
structure of the example is that there is one procedure definition,
which takes upwards of 700 parameters, (uses almost none of them
internally) and tail-calls itself with them.  So to intraprocedural
dead code elimination it looks like deep down in the bowels of this
huge procedure there are 700 live variables.  Since lets have already
been lifted by this point, these 700 live variables have to percolate
through a very large number of one-binding let forms, each of which
occasions a union with the small handful of variables that let binds.
Now, this pass represents sets as unordered lists.  In this
representation, with the particular algorithm used, computing the
union of sets of size k_1 and k_2 takes time proportional to k_1k_2 +
(1/2)k_2^2.  Having k_1 be on the order of 1 and k_2 on the order of
700, for some hundreds of occurrences of this, was, shall we say, an
opportunity for improvement.

I seem to have the pattern that the length of my commit messages is
inversely proportional to the quantity of code change I am explaining.

axch/dysvunctional-language,axch/dysvunctional-language,axch/dysvunctional-language,axch/dysvunctional-language