>
> I guess what I wanted to say is that a function created with
> Prototype's `bind` (internally) has a predictable closure - the one
> that's got formed when a function was declared. And it is declared by
> Prototype, inside a very "slim" scope (self-executing function,
> surrounding `Function.prototype` extensions). That scope has no heavy
> objects, no host objects (!) and so when bind internally creates a
> function, that function closure consumes a relatively small amount of
> memory.
That has me thinking. Do the closures really consume as much additional
memory as the entire host scope's execution context, plus it's own, or just
the added pointers to the variables it actually closes over (i.e. uses
within it). I.e., are the interpreters smart enough to create the new
execution context in any sort of optimized manner?
If not, then wouldn't it just not matter? If it duplicates the entire host
context's memory footprint, then would that not lead all the way up to the
main (window) context, presumably? Therefore, your statement of .bind()'s
closure being "thin" isn't necessarily true, as it would derive from a
function chain relative to where .bind() actually gets called anyway,
ultimately closing over the entire global namespace (as do all functions).
Also, does it really consume additional memory for that closed over context,
or simply pass it in by reference, thus it being truly shared memory. Again,
I would have to believe it's not a O(log n) operation... that would truly
result in major memory consumption. My GUESS is, it's about a horse a piece
(6 one way, half a dozen the other).
Interesting. I wonder if there are tools around to profile a javascript
context tree and see what's going on with this.
At any rate... I used to be "bind happy", as I think most people are, but
now implement a pattern that precludes having to use it almost ever. Really
the only time I employ it these days is if I get lazy. The modified module
pattern I described in that other thread really does away with the need to
use it (i.e. create functions within the context in which they are needed,
or pass the instance in)... I've become a bit more "functional" with my js
these days.
Also, RE: your comment about deeply nested function definitions being an
indicator of poor design... it's often a good technique to actually _save_
on resources (lazy definitions), wherein the memory for the function is not
set aside until it's actually needed (assuming you use "var foo = function()
{};" instead of "function foo() {}", as the latter results in memory
allocation immediately with some interpreters). So it _can_ be good design.
Ryan Gahl
CEO
Nth Penguin, LLC
http://www.nthpenguin.com
--
Inquire: 1-920-574-2218
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl
>
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---
