Nice technique and proposed idiom. (I also loved the Why combinator pun. :-)
dvb
· 3 years ago
First -- I have been very much enjoying your blog. Very thought provoking and inspiring! As ever, your approach is simultaneously academic and practical.
This article taught me a few new words (nullary, memoize) which will come in handy, and a few more of JavaScript's subtleties.
So, memoization. I like it. But I'm just a simple engineer unconcerned with language theory, and more concerned with getting stuff to work good, and stuff. Keith Gaughan's solution -- appending .memoize() -- onto a function certainly seems the least intrusive and tidy. And, agreed, managing multiple files and dependencies on a server is annoying. One solution for that would be to introduce a build-step to the development, resulting in a single file. Yeah... Edit, make, test. It's not the craziest flow in the world, though it is one more darned thing.
Reassigning the function to "return length" is appealing but troubling. It's an opaque state, it's self-modifying code, oh, it troubles me. And even more so for the self-neutralizing "Thing.noFun = function(){};"!
While these strategies are interesting, I'm always concerned that my code may be maintained by cave men, or myself late on a Sunday. These dynamic features are, obviously, a lot of fun... but I must confess: I'll opt for the first naive "Thag not compute Bezier length twice if Thag already have Bezier length! Ha!" solution: function bezierLength() { compute if needed, return }". Easy peasy.
Victor Laszlo
· 3 years ago
Nice article oliver. I have to say that this restriction: > The inner function captures the variables from the outer function.
makes me a little suspicious of the fancier solutions you present. It's true that the memoization is caught up in the domain logic, but I have needed to do this rarely enough that it hasn't really bothered me. I'm more wary of memory leaks or ineffeciencies in the underlying runtime when using closures than bugs caused by rewriting a little code to test for the presence of a stored value.
Also, here's another take on your memoization routine that uses arguments.callee instead of closures.
function assignMemoizable( object, func , name ){ var f = function (){ if stored value exists return from cache else return arguments.callee.originalFunction.apply( this , arguments ); } f.originalFunction = func; object.prototype[ name ] = f; }
Inner functions should only need to capture their free references. Are you just saying that most Javascript VM's are too simplistic, so they capture the entire scope chain? Bleah.
Peter Williams » JavaScript Is
· 3 years ago
[...] While reading Oliver Steele’s article on JavaScript Memoization this bit jumped out at me. [...]
Steffen
· 2 years ago
Just as a sidenote: Trying to subscribe to any of the feeds, be it rss or atom, gives a 500.
ben lowery » Thursday
· 2 years ago
[...] For a “simple” language, Javascript is amazingly deep. Learning how to use a language with closures and runtime function generation just takes a shift in thinking from anything else I’ve done. The whole concept of memoization is just amazing. I think I’ve fallen off the strong-typing bandwagon. Oh if Bart could see me now… [...]
Ryan Johnson
· 2 years ago
Great stuff! I think you would enjoy this as well:
This strikes me as something I might actually use in a number of practical cases though. Thanks for going into such detail, great explanations.
Bas Wenneker
· 2 years ago
Very cool technique, I wrote something like this in java some time ago, never thought about a javascript implementation. Great content you have on your blog! Thanks
atany
· 2 years ago
Great article!
Could you please correct shortened memoizeConstantMethod to define local 'value' variable :)
The current version does not work correctly when called more then once for different methods.
Daily misery » Blog Archive »
· 2 years ago
[...] One-Line JavaScript Memoization at Oliver Steele [...]
Links of the day « Geeks in th
· 2 years ago
[...] One line memoization in javascript [...]
Oliver
· 2 years ago
Atany: thanks for the catch; 'tis done.
Timed Memoization
· 1 year ago
[...] One-Line JavaScript Memoization by Oliver Steele [...]
playBunny
· 1 year ago
Why create a closure when you can just create a plain old function? It looks as simple as it is. No need to complicate things by calling the new function either.
Bezier.prototype.getLength = function() { var length = ... // expensive computation this.getLength = new Function ("return " + length); return length; }
Cheap Airsoft Electric Guns
· 1 year ago
Looks like it would work to me. Remember there are more than one way to skin a cat.
All Comments
This article taught me a few new words (nullary, memoize) which will come in handy, and a few more of JavaScript's subtleties.
So, memoization. I like it. But I'm just a simple engineer unconcerned with language theory, and more concerned with getting stuff to work good, and stuff. Keith Gaughan's solution -- appending .memoize() -- onto a function certainly seems the least intrusive and tidy. And, agreed, managing multiple files and dependencies on a server is annoying. One solution for that would be to introduce a build-step to the development, resulting in a single file. Yeah... Edit, make, test. It's not the craziest flow in the world, though it is one more darned thing.
Reassigning the function to "return length" is appealing but troubling. It's an opaque state, it's self-modifying code, oh, it troubles me. And even more so for the self-neutralizing "Thing.noFun = function(){};"!
While these strategies are interesting, I'm always concerned that my code may be maintained by cave men, or myself late on a Sunday. These dynamic features are, obviously, a lot of fun... but I must confess: I'll opt for the first naive "Thag not compute Bezier length twice if Thag already have Bezier length! Ha!" solution: function bezierLength() { compute if needed, return }". Easy peasy.
> The inner function captures the variables from the outer function.
makes me a little suspicious of the fancier solutions you present. It's true that the memoization is caught up in the domain logic, but I have needed to do this rarely enough that it hasn't really bothered me. I'm more wary of memory leaks or ineffeciencies in the underlying runtime when using closures than bugs caused by rewriting a little code to test for the presence of a stored value.
Also, here's another take on your memoization routine that uses arguments.callee instead of closures.
function assignMemoizable( object, func , name ){
var f = function (){
if stored value exists
return from cache
else
return arguments.callee.originalFunction.apply( this , arguments );
}
f.originalFunction = func;
object.prototype[ name ] = f;
}
That seems like it would work too, no?
http://www.cs.cityu.edu.hk/~hwchun/31337/blog/2...
This strikes me as something I might actually use in a number of practical cases though. Thanks for going into such detail, great explanations.
Could you please correct shortened memoizeConstantMethod to define local 'value' variable :)
The current version does not work correctly when called more then once for different methods.
Bezier.prototype.getLength = function() {
var length = ... // expensive computation
this.getLength = new Function ("return " + length);
return length;
}