Earlier quoted context omitted.
It is, though. It doesn’t speed up function execution, but it literally speeds up the function call.
It only speeds up calls to pure (side-effect free) functions, that have been executed before with these exact parameters and where the result is still cached. All other calls get slower. Also, there's an argument to be made that "function call" is the overhead involved in moving control from the call site to the callee (which can be significant in interpreted languages such as Python). That's at least how I interpret…
Speeding up function calls with lru_cache in Python
51–60 of 85 posts
Re: Speeding up function calls with lru_cache in Python
#52Maybe I'm abusing lru_cache but another use for it is debouncing. We had a chatbot that polls a server and sends notifications, but due to clock skew it would sometimes send two notifications. So I just added the lru_cache decorator to the send(username, message) function to prevent that.
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?
Re: Speeding up function calls with lru_cache in Python
#53Re: Speeding up function calls with lru_cache in Python
#54Re: Speeding up function calls with lru_cache in Python
#55Re: Speeding up function calls with lru_cache in Python
#56(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
#57Instead of the last quote in the article, I prefer this one (got it from [0]) >"There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors." – Martin Fowler And there's plenty of similar articles, for example [1] [2] [0] https://www.mediawiki.org/wiki/Naming_things [1] https://dbader.org/blog/python-memoization [2] https://mike.place/2016/memoization/
Even in this version, the quote still feels incomplete without someone shouting "Concurrency!" while it is delivered...
Re: Speeding up function calls with lru_cache in Python
#58> @functools.lru_cache Avoid these tricks if you care about thread safety.
Re: Speeding up function calls with lru_cache in Python
#59> 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/Noct…
If this theory is correct, every recursive function f(n) requiring access to f(n-x) should have x+1 as maximum usefull cache size.
Re: Speeding up function calls with lru_cache in Python
#60(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.
For small values, the iterative version works just fine. For larger values, there are other methods: one obvious one is using the matrix form of the Fibonacci numbers, which just requires you to take an exponent of a 2x2 matrix (which you can do quickly because of exponentiation by squaring).