The Advent of Code 2024 Day 11 problem featured labeled rocks which duplicate according to simple rules:

• Rocks labeled 0 turn into 1's
• Rocks with a even number of digits in the label split into two rocks with the first and last half of the digits
• Other rocks have their labels multiplied by 2024

Your puzzle task is to count the number of rocks after 25, then 75 iterations of these rules.

For 25 iterations, a very simple recursive count suffices

count := proc(n, s)
local f, l;
    if n = 0 then return 1;
    elif s=0 then return count(n-1,1);
    end if;
    l := length(s);
    if l mod 2 = 0 then
         f := floor( s/10^(l/2) );
         return count(n-1,f) + count(n-1,s-f*10^(l/2));
    else return count(n-1, 2024*s);
    end if;
end proc:

For the puzzle input, a collection of 8 numbers (the stone labels) the largest with 7 digits, you can call count(25,s) on each s in the input and add them together in about 1 second, but trying that for 75 "hangs" and clearly will not work.

Generally for something like this, the first trick in my puzzle solving toolbox is memoization, so that the results of recursive calls are stored so they don't have to be recomputed.  In Maple, there are two main ways to add memoization to recursive procedures: option cache and option remember.  The remember option is older and uses a simple table that gets populated with (input,return) pairs whenever the procedure returns. The cache option is newer and uses size limited LRU tables that are more memory friendly.  Typically in the Maple math library we use cache tables since they won't fill up your working memory with cached results, and will remove old cached elements in a smart way (the double option option remember, system also limits table growth by allowing entries to be garbage collected, but it is not as flexible as a cache).

So this preable is to say, that the first memoization option I tend to reach for is option cache but best practice for Maple math library development is not always the thing that solves a code puzzle.  In this case, adding option cache to our procedure count also "hangs".  If you are smart, you will immediately try again with option remember, and you'll find that works easily:

count := proc(n, s)
option remember;
    if n = 0 then return 1;
    elif s=0 then return count(n-1,1);
    end if;
    local l := length(s);
    if l mod 2 = 0 then
         local f := floor( s/10^(l/2) );
         return count(n-1,f) + count(n-1,s-f*10^(l/2));
    else return count(n-1, 2024*s);
    end if;
end proc:
ans1 := CodeTools:-Usage( add( map2(count, 25, input) ) ); # 17ms
ans2 := CodeTools:-Usage( add( map2(count, 75, input) ) ); # 825ms

So why does remember work, when cache fails so spectacularly? Well, you can create a function with a cache, call it once create it and the examine the Cache object with op:

> cacheFunc := proc() option cache; args; end proc:
> cacheFunc(1): op( 4, eval(cacheFunc) );

                       Cache(512, 'temporary' = [1 = 1])

You can see here that the default cache is 512 entries which is a pretty good default for general use, but way way too small for this ridiculous puzzle problem.  Fortunately, the cache option allows you to specify a size to create a much bigger cache for a highly recursive procedure like this one.  I tested caches of various sizes (cache always rounds up the next power of 2) and compared to option remember and remember, system.

1. option remember  - 707ms
2. option remember, system - 4.22s
3. option cache  - too slow, killed after hours
4. option cache(1024) - 30.21s
5. option cache(16384) - 5.60s
6. option cache(131072)- 726ms
7. option cache(1048576)- 806ms

So, for this problem, it looks like a 2^17=~100,000 entry cache (#6) gives about the same performance as a remember table, so it's not surpring a larger cache does no better. 

In fact, since results are not removed from an option remember table, you can actually check exactly how many results were cached and see it is just less than 2^17.

> add( map2(count, 75, input) ): numelems( op(4, eval(count) ) );
                                    120076

And the take away is, for this sort of puzzle solving you should try option remember even if option cache is usually a better choice when implementing a more serious mathematical algorithmn that wants to occasionally needs to reuse results.