Slow compilation with long method chains

[satyr]

Reported by statim on #coffeescript:

(statim) ok, this is interesting… i guess it IS continuing through these things, it just takes 3-4 minutes when it gets stuck. i finally let the thing just sit there, and it did eventually continue. i guess any ideas on whats up with that now? :)

(statim) matyr and anyone else interested.. i made these changes after upgrading to 1.0: https://gist.github.com/c0bce8f7eeb76369b75b it seems in 1.0 coffeescript gets hung up on long-chained code… and it seems to be exponential. it eventually will complete but really slows down compliation

[jashkenas]

I've tracked down the slowness to unfoldSoak, in both Call and Value -- it's getting called way too many times.

It just keeps branching out horizontally like this:

[mjmsmith]

I'm using LAB.js for script loading, with code like this:

$LAB.script('foo.js').script('bar.js').script('baz.js') etc etc

In my development environment, this chain is about 20 calls and it now takes minutes to compile. I assume that long jQuery chains would have the same problem.

[ress]

I ran into this problem today and measured compile speed with increasing call chains. The compile time started growing exponentially after 15 chained calls. It doesn't matter whether parameters are passed or not, nor if it's the same method.

Benchmark code is here: https://gist.github.com/924670

[jashkenas]

I tried a couple different tacks at this, but this little memoization fix seems to work, and is minimally invasive. Now you can compile source files like this without issue:

a.a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a()
 .a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a()
 .a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a()
 .a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a()
 .a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a()
 .a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a()
 .a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a()
 .a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a().a()

I'm still a little uncomfortable with unfoldSoak in general. It allows us to have syntax like this work:

eq undefined, a?.b.c += 1

Which means that the outer operation really has to be able to walk down to the inner soak, and do the right thing. But it's also kind of magical. If we lost the ability to have these sorts of soaked expressions, the code would become a good deal simpler.

[satyr]

I'm still a little uncomfortable with unfoldSoak in general

Reopen #756?