I think you are one of the finest JavaScript teacher on UA-cam. Crisped content, simple explanations, no unnecessary dragging of topic, no product placement in video. Thanks and keep going.
Thanks Steve. I did something like this about a year and a half ago in a time management and reporting system and it massively sped up things. Many times, the same reporting information showed up across various reports. Brought our cold report load time down to 7 seconds and our hot reload time to about 2. It was a minute and a half before.
@@SteveGriffith-Prof3ssorSt3v3 then we would need some data base to store some user's data right How could that be done? May I know? I mean any tutorial on that?
Hey Steve, thanks for the videos. Do you like vim editor ? What are your thoughts ? I've coded hundreds of lines of code in vimscript with only a handful of plugins and I still don't think I have gotten it where I need it at lol.
I guess the range of input values determines the size the memo variable could grow. Could that be a problem for functions running in a node server, per instance? They may be running for months or even years.
memoization is a trade off. You trade memory for performance. It is a judgement call. Let's say that the function will be running for a year without a restart. How many different results will you get from the function (memory used) versus how long does it take to run each time? Are there lots of calls that happen at the same time and we need to speed up the function to aid performance? If you have say 300 possible results that is a small price to pay if it cuts the execution time by 60%.
@@SteveGriffith-Prof3ssorSt3v3 ok, I think I've got it - I'm not sure if it's exactly to do with it being a closure, but it is the arrow function that gets returned to the 'result' variables each time the IIFE is called. The memo variable just happens to have been declared and assigined in the IIFE, where it will persist in memory, since the IIFE it is in, persists in memory. The same, I'm guessing will probably had worked if memo was declared outside the IIFE using var, which is not a problem here as there are no loops or async operations. Thanks for the great tutorials again, btw!
@@SteveGriffith-Prof3ssorSt3v3 Got it! I think I was confusing the returned arrow function with the function that generated the arrow function. But yes, it makes sense now - a closure gets created (around the variable) so that the arrow function can access a variable outside its scope, later on!
Very informative. So this is basically using closures to cache the results. I am wondering though, wouldn't this cause kind of a memory leak if the function is called with a lot of different values?
Basically, no. A memory leak is when, due to some memory management issues, some amount of memory that is supposed to be free is occupied. When you memoize a function, the value returned based on the arguments that were given will be cached until it is needed again. When it is needed again is unknown aka forever, so this amount of memory is not supposed to be free. If by any chance you feel like it's an inefficient usage of memory, then you should take a look at why you're memoizing that particular function. I think that if the arguments and values returned are always different or rarely ever the same, then there's no point in memoizing that function.
Thanks Shenesh for that helpful answer. With memoization what we are doing is making an intentional choice to use more memory in exchange for a specific performance improvement. There are two questions that you need to ask before using this technique. 1. Will my function require a lot of processing time? If not then don't use memoization. 2. Will the function be used frequently with the same input values? If not then don't use memoization.
@@sheneshperera Thanks for your reply. I didn't mean literally a memory leak. It's just that if you call the factory many times with different arguments, you can end up with a lot of functions all taking up memory.
I think you are one of the finest JavaScript teacher on UA-cam. Crisped content, simple explanations, no unnecessary dragging of topic, no product placement in video. Thanks and keep going.
Is it only me that likes these vids before even watching them 😂? Thanks, in advance, prof! Let me now watch my video in peace 😂
You renewed me
Now I understand what this concept is in react, finally
Thanks. Glad I discovered your channel
I love your voice. So soothing. You content is amazing too.
Thanks Steve. I did something like this about a year and a half ago in a time management and reporting system and it massively sped up things. Many times, the same reporting information showed up across various reports. Brought our cold report load time down to 7 seconds and our hot reload time to about 2. It was a minute and a half before.
Another very cool tutorial!
Thanks for these videos Steve!
in this case once we run it again everything starts from again right I mean there's no property in memo object
If you mean reload the web page or restart the node script, then yes, all variables and their contents are gone
@@SteveGriffith-Prof3ssorSt3v3 then we would need some data base to store some user's data right
How could that be done? May I know?
I mean any tutorial on that?
Hey Steve, thanks for the videos. Do you like vim editor ? What are your thoughts ? I've coded hundreds of lines of code in vimscript with only a handful of plugins and I still don't think I have gotten it where I need it at lol.
Please make a series of algorithms and data structure in js
Please put your requests in the comments here - ua-cam.com/video/LCezax2uN3c/v-deo.html
or vote with thumbs up if your ideas are already listed.
I guess the range of input values determines the size the memo variable could grow. Could that be a problem for functions running in a node server, per instance? They may be running for months or even years.
memoization is a trade off. You trade memory for performance. It is a judgement call. Let's say that the function will be running for a year without a restart. How many different results will you get from the function (memory used) versus how long does it take to run each time? Are there lots of calls that happen at the same time and we need to speed up the function to aid performance?
If you have say 300 possible results that is a small price to pay if it cuts the execution time by 60%.
@@SteveGriffith-Prof3ssorSt3v3 You're very right. Thank you!
Doesn't the variable const memo get cleared out each time a copy of myFunc is created, due to block/function scope?
A closure gets created around the memo variable so it is saved for later reference.
@@SteveGriffith-Prof3ssorSt3v3 ok, I think I've got it - I'm not sure if it's exactly to do with it being a closure, but it is the arrow function that gets returned to the 'result' variables each time the IIFE is called. The memo variable just happens to have been declared and assigined in the IIFE, where it will persist in memory, since the IIFE it is in, persists in memory. The same, I'm guessing will probably had worked if memo was declared outside the IIFE using var, which is not a problem here as there are no loops or async operations. Thanks for the great tutorials again, btw!
That is the closure - a returned function that accesses a variable outside of its scope. The closure is created around the variable because of that.
@@SteveGriffith-Prof3ssorSt3v3 Got it! I think I was confusing the returned arrow function with the function that generated the arrow function. But yes, it makes sense now - a closure gets created (around the variable) so that the arrow function can access a variable outside its scope, later on!
Very informative. So this is basically using closures to cache the results. I am wondering though, wouldn't this cause kind of a memory leak if the function is called with a lot of different values?
Basically, no. A memory leak is when, due to some memory management issues, some amount of memory that is supposed to be free is occupied. When you memoize a function, the value returned based on the arguments that were given will be cached until it is needed again. When it is needed again is unknown aka forever, so this amount of memory is not supposed to be free.
If by any chance you feel like it's an inefficient usage of memory, then you should take a look at why you're memoizing that particular function. I think that if the arguments and values returned are always different or rarely ever the same, then there's no point in memoizing that function.
Thanks Shenesh for that helpful answer.
With memoization what we are doing is making an intentional choice to use more memory in exchange for a specific performance improvement. There are two questions that you need to ask before using this technique.
1. Will my function require a lot of processing time? If not then don't use memoization.
2. Will the function be used frequently with the same input values? If not then don't use memoization.
@@sheneshperera Thanks for your reply. I didn't mean literally a memory leak. It's just that if you call the factory many times with different arguments, you can end up with a lot of functions all taking up memory.
Awesome !