> As, we can see the optimal cache size of fib function is 5. Increasing cache size will not result in much gain in terms of speedup. Try it with fib(35), curious what you find.
Speeding up function calls with lru_cache in Python
41–50 of 85 posts
Re: Speeding up function calls with lru_cache in Python
#42Re: Speeding up function calls with lru_cache in Python
#43Note that `lru_cache` doesn't just do caching, it also provides convenient methods on the original function to get cache stats etc in a pythonic way.
Re: Speeding up function calls with lru_cache in Python
#44> As, we can see the optimal cache size of fib function is 5. Increasing cache size will not result in much gain in terms of speedup. Try it with fib(35), curious what you find.
Why would fib(35) be more optimal with a differently sized cache? And how come _5_ is optimal? Wouldn’t 2 be all you need? What am I missing?
Because of the way the recursion goes down the tree depth-first, I think 5 basically cuts down the computation to fib(10-5) = fib(5) which is pretty manageable, so the author couldn't really see any further measurable performance gains by increasing the cache further. I think for fib(35) it'd be clear that cache size 35 would help compared to cache size 5. (I picked 35 instead of, say, 300, because I think 300 would just not finish with cache size 5, it'd take forever haha.)
Re: Speeding up function calls with lru_cache in Python
#45(Fibonacci numbers have a closed form analytic solution that can be computed in constant time: https://www.evanmiller.org/mathematical-hacker.html )
Re: Speeding up function calls with lru_cache in Python
#46Re: Speeding up function calls with lru_cache in Python
#47(Fibonacci numbers have a closed form analytic solution that can be computed in constant time: https://www.evanmiller.org/mathematical-hacker.html )
Re: Speeding up function calls with lru_cache in Python
#48> As, we can see the optimal cache size of fib function is 5. Increasing cache size will not result in much gain in terms of speedup. Try it with fib(35), curious what you find.
Why 3 is optimal, because of how recursion and LRU work. I wish i can explain it using animation.
You can play with it. https://repl.it/repls/NocturnalIroncladBytecode#main.py
Re: Speeding up function calls with lru_cache in Python
#49Re: Speeding up function calls with lru_cache in Python
#50Earlier quoted context omitted.
That sounds very interesting. Can you detail the problem a bit (I'm not sure I understand how clock skew affects python code) and how lru_cache decorator fixed it?
Essentially the OP is using the decorator to prevent the function call from ever being run more than one time. It’s at most once.