Groovy's trampoline() makes recursive execution much slower - why?

Question

I'm experimenting with recursion:

def fac
//fac = { int curr, res = 1G -> 1 >= curr ? res : fac( curr - 1, res * curr ) }
fac = { int curr, res = 1G -> 1 >= curr ? res : fac.trampoline( curr - 1, res * curr ) }
fac = fac.trampoline()

def rnd = new Random()

long s = System.currentTimeMillis()

100000.times{ fac rnd.nextInt( 40 ) }

println "done in ${System.currentTimeMillis() - s} ms / ${fac(40)}"

If I use it like this, I'm getting this:

done in 691 ms

If I uncomment line #2 and comment lines #3-4 to remove trampoline() and run it, I'm getting significantly lower numbers:

done in 335 ms

So, with trampoline the recursion works 2 times slower.

What am I missing?

P.S.

If I run the same example in Scala 2.12:

def fac( curr:Int, acc:BigInt = 1 ):BigInt = if( 1 >= curr ) acc else fac( curr - 1, curr * acc )
val s = System.currentTimeMillis
for( ix <- 0 until 100000 ) fac( scala.util.Random.nextInt(40).toInt )

println( s"done in ${System.currentTimeMillis - s} ms" )

it executes a bit faster:

done in 178 ms

UPDATE

Rewriting the closure to a method with the annotation:

@groovy.transform.TailRecursive
def fac( int curr, res = 1G ) { 1 >= curr ? res : fac( curr - 1, res * curr ) }
// the rest

gives

done in 164 ms

and is super-coll. Nevertheless, I still want to know about trampoline() :)

Answer 1

As stated in the documentation, Closure.trampoline() prevents from overflowing the call stack.

Recursive algorithms are often restricted by a physical limit: the maximum stack height. For example, if you call a method that recursively calls itself too deep, you will eventually receive a StackOverflowException.

An approach that helps in those situations is by using Closure and its trampoline capability.

Closures are wrapped in a TrampolineClosure. Upon calling, a trampolined Closure will call the original Closure waiting for its result. If the outcome of the call is another instance of a TrampolineClosure, created perhaps as a result to a call to the trampoline() method, the Closure will again be invoked. This repetitive invocation of returned trampolined Closures instances will continue until a value other than a trampolined Closure is returned. That value will become the final result of the trampoline. That way, calls are made serially, rather than filling the stack.

---

^{Source: http://groovy-lang.org/closures.html#_trampoline}

However, using trampoline comes with a cost. Let's take a look at the JVisualVM samples.

Non-trampoline use case

Running an example without trampoline() we get a result in ~441 ms

done in 441 ms / 815915283247897734345611269596115894272000000000

This execution allocates ~2,927,550 objects and consumes around 100 MB of memory.

The CPU has a little to do, and except spending time on main() and run() methods, it spends some cycles on coercing arguments.

The trampoline() use case

Introducing the trampoline does change a lot. Firstly, it makes execution time almost two times slower compared to the previous attempt.

done in 856 ms / 815915283247897734345611269596115894272000000000

Secondly, it allocates ~5,931,470 (!!!) objects and consumes ~221 MB of memory. The main difference is that in the previous case a single of $_main_closure1 was used across all executions, and in case of using trampoline - every call to trampoline() method creates:

• a new $_main_closure1 object
• which gets wrapped with the CurriedClosure<T>
• which then gets wrapped with the TrampolineClosure<T>

Only this allocates more than 1,200,000 objects.

If it comes to the CPU, it also has much more things to do. Just look at the numbers:

• all calls to TrampolineClosure<T>.<init>() consume 199 ms
• using trampoline introduces calls to PojoeMetaMethodSite$PojoCachedMethodSietNoUnwrap.invoke() which in total consume additional 201 ms
• all calls to CachedClass$3.initValue() consume in total additional 98.8 ms
• all calls to ClosureMetaClass$NormalMethodChooser.chooseMethod() consume in total additional 100 ms

And this is exactly why introducing trampoline in your case makes the code execution much slower.

So why @TailRecursive does much better?

In short - @TailRecursive annotation replaces all closures and recursive calls with good old while-loop. The factorial function with @TailRecursive looks something like this at the bytecode level:

//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by Fernflower decompiler)
//

package factorial;

import groovy.lang.GroovyObject;
import groovy.lang.MetaClass;
import java.math.BigInteger;
import org.codehaus.groovy.runtime.ScriptBytecodeAdapter;
import org.codehaus.groovy.runtime.dgmimpl.NumberNumberMultiply;
import org.codehaus.groovy.transform.tailrec.GotoRecurHereException;

public class Groovy implements GroovyObject {
    public Groovy() {
        MetaClass var1 = this.$getStaticMetaClass();
        this.metaClass = var1;
    }

    public static BigInteger factorial(int number, BigInteger acc) {
        BigInteger _acc_ = acc;
        int _number_ = number;

        try {
            while(true) {
                try {
                    while(_number_ != 1) {
                        int __number__ = _number_;
                        int var7 = _number_ - 1;
                        _number_ = var7;
                        Number var8 = NumberNumberMultiply.multiply(__number__, _acc_);
                        _acc_ = (BigInteger)ScriptBytecodeAdapter.castToType(var8, BigInteger.class);
                    }

                    BigInteger var4 = _acc_;
                    return var4;
                } catch (GotoRecurHereException var13) {
                    ;
                }
            }
        } finally {
            ;
        }
    }

    public static BigInteger factorial(int number) {
        return factorial(number, (BigInteger)ScriptBytecodeAdapter.castToType(1, BigInteger.class));
    }
}

I have documented this use case on my blog some time ago. You can read the blog post if you want to get more information:

https://e.printstacktrace.blog/tail-recursive-methods-in-groovy/