Using caching and memoization to optimize Python performance

[@cjayhorton6356]

Hi Sebastiaan, this video was great. I really appreciate that you chose non-trivial functions to illustrate this.

[@eyalfrish]

Yet another nicely put video!!! BTW, you mentioned you don’t understand the use of “lru” (least recently used) in the specific context you used it. I would like to clarify why it does make sense ;).. The “lru” indicates the caching-mechanism’s replacement/evacuation policy, meaning, in case you do limit the cache’s size (with maxsize), the “algorithm” that will be used to chose which of the already-cached maxsize calls/return-values to replace with the next non-cached call/return-value. In the “lru” case, the item that will be replaced is the one that was least-recently used, hence, this algorithm’s best performance will be when the most recent calls are really the best predictors for your next/future calls. I hope that helps a bit ;)!

Thanks for clarifying that!

[@michakwiatek2076]

Great explaination as always, thanks Sebastiaan!

[@btcjj955]

Awesome explanation. Please make more such short and concise videos.

[@zeroxd.cypher3899]

this needs way more views. thanks allot for this

[@benyaminyakobi3652]

Thank you, very clear explanation!

[@hahahihi6253]

Really great work. Your explanations are awesome! Thank you 👍

[@AjitSingh-rg3zu]

Thanks for the wonderful explanation

[@nitinpandey7478]

Nicely explained

[@raspreetsingh5542]

Great stuff!

[@sergeyv1534]

Good lesson!

[@Philogy]

Nice video, I have a few questions about the decompose function shown in the video: 1. Does one need to use `decompose(y)` (on line 18) couldn't one just write `[y]` since the first valid y found will be a prime number anyway or did you apply decompose again so that the `[y]` would be cached? If so would that really be faster than just `[y]`? Wouldn't the readability of `[y] + decompose(x // y)` be better? 2. Also shouldn't `x

Hi Philippe, thanks for thinking about this in so much detail! I think you're correct on each of these points! Re 5: no, there's undoubtedly faster ways to determine whether a number is prime!

[@korkunctheterrible4302]

How does it matter what range he writes when he's gonna return the function as soon as the smallest prime factor checks? It's not like he was trying to list all the prime factors that divide evenly into the input, he's instead doing a total factorization that recurses at the first smallest prime factor it encounters. For instance, if the input were 8, there'd be 4 primes up to 8 but only 1 of them would be a factor 3 times, it woudn't ever check for 3-8 anyway . So can you please tell me what I'm missing?

[@mehdi-vl5nn]

i believe is dynamic programming using recursive functions called memoization

[@onlymusic2005]

Great performance, ❤️

[@sishuiutchiwa5762]

I don't understand one think at 1:21 when you spoke for an exemple about the square root fonction,you said that if we call that fonctions square root(9)twice we will get 3,but why we call the fonctions twice? Why we don't use it for one time?

[@himanshuchauhan1015]

it's supposed that the function call is needed to call twice, it can be simultaneously or after some time or after some other things complete

[@memyaccount8213]

The specific reason doesn't matter; it's more about how it would be recalculating the square root in the same way each time it's called. But with memoization, it wouldn't be recalculated in the same way as the first time it was called--instead, it would use what was stored from the first call, in order to more efficiently give you the answer.

[@DanielDelgado-ge7rs]

Te amo

[@cryptobitez6090]

I don't understand how the decompositon func returns a list, it just returns a decomp of y + decomp of remainder....how does that return a list without a list being created in the function to store the values for each loop?

[@korkunctheterrible4302]

The recursion base case is when x in [x] is a prime number. so let's say we call the func on 12: dec(12) * return dec(2) + dec(6) dec(2) for y in range(2,2) means for nada times, out of the loop, return [2] - - - > our initial list , and the return statement above has now become: return [2] + dec(6) dec(6): *return dec(2) + dec(3) dec(2) returns [2] again, (probably this is what is memoized/returned from cache), so the return statement is now return [2] + [2] + dec(3) now we look at dec(3): for y in range(2,3): - - - >the only iteration is y=2 and since 3 % 2 != 0 therefore truthy, the if block is not executed yet again, and [3] is returned out of the loop the original return statement becomes [2, 2] + [3] which is [2, 2, 3 ] the plus sign can merge lists like this, I think it's "in-place", lists are mutable, although the addition is not the same as .append(), it bears the same results in such cases The trick here is that only part of the first return statement that calls decompose on a prime number exits recursion and initiates the list and only the part of the first return statement that's still a composite number continues on with the recursion, always returning dec(smallest prime factor) + dec(new composite number).

[@pliniado]

@@korkunctheterrible4302 Thank you very much! I was struggling with the same difficult. Very clear explanation.

[@Tntpker]

Why does random_prime also increase in speed when it's not decorated?

[@jampk24]

The random_prime() function uses the decompose() function, so if you speed up decompose() then you're also speeding up random_prime().

[@Tntpker]

@@jampk24 cheers

[@larrysummer2015]

A function that calls itself 😢.. I gotta learn more about