I'm finding that large subs seem to give imcc headaches. I'm not sure
if it's O(n^2) or O(2^n) headaches, but definitely issues. At the
moment I've got parrot churning on some pir code and it's taking
quite a while. Final time tally:

real    41m46.978s
user    21m24.300s
sys     0m41.080s

Ended with a missing symbol error, of course, just to rub it in a
bit. vm_stat reports a lot of zero-fill page allocation (about 1600
4K pages/sec) though the memory footprint isn't growing to match, so
that might indicate at least something of the problem. (For all I
know there's some sort of degenerate GC issue somewhere, depending on
how imcc does its memory allocation and management)

I know IMCC's being redone, and we're nowhere near close to
optimized, but I think it'd be worth it to get a handle on what sorts
of things are likely to trigger off exponential time compiles when
fed to IMCC. I'm assuming that it's due to a combination of sub size
(about 61K of source in one sub) and locals needing coloring (132)
but it'd be nice to know for sure.

For me, reducing the size of the sub's untenable, but I can switch
from using locals to using pad or global variables that get fetched
as need be if that means less compile time.
--
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk