Live data from Hacker News

Speeding up function calls with lru_cache in Python

hackeregg.github.io

41–50 of 85 posts

Re: Speeding up function calls with lru_cache in Python

#41

> 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?

Re: Speeding up function calls with lru_cache in Python

#44
post #41

> 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?

I think it's likely that the author's analysis of why 5 is the optimal cache size heavily depends on the fact that they only tried fib(10). For example, it's clear that cache 20 and cache 30 are identical if your universe of possible inputs is only [0 .. 10], haha.

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 )

Does this work in practice for large values of n? You will be limited by numerical error in phi.

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.

After, reading your comment. I cross checked result and found out that 3 is most optimal size. I even ran fib(40) on it. with size 2, There are many misses but after 3 and on wards misses are constant(if fib(40), then misses are only 40 which emulates DP approach of O(N)).

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

#49
I had worked on a open source project called 'safecache' on the similar note. As others has already commented, @lru_cache does not play well with mutable data structures. So my implementation handles for both immutable and mutable data structures as well as multi-threaded operations.

https://github.com/Verizon/safecache

Re: Speeding up function calls with lru_cache in Python

#50

Earlier 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.

More specifically, it prevents a call being repeated _in quick succession_, if there are enough calls in between repetitions it'll fall out of the cache and be reprocessed.
Post reply on HN