Re: FunctionExpression's and memory consumptions

On Oct 28, 7:49 am, kangax <kan...@xxxxxxxxx> wrote:
On Oct 26, 10:49 pm, dhtml <dhtmlkitc...@xxxxxxxxx> wrote:



kangax wrote:
There's a common pattern of "forking" a returning function as in the
following example:

function bind(fn, context) {
  var args = Array.prototype.slice.call(arguments, 2);
  if (args.length) {
    return function() {
      fn.apply(context, args);
    }
  }
  return function() {
    return fn.call(context);
  }
}

The runtime speed benefits are obvious, but I've been told that there
is an increased memory consumption in such cases. Are there 2 Function
objects created when `bind` is being called? I assume that's not the
case, since those are not FunctionDeclaration's, but rather
FunctionExpression's (and so they should not be evaluated foremost
when execution context is entered). Are FunctionExpression's contained
within blocks that are never evaluated create Function objects? Does
it make a difference if FunctionExpression is contained within a
`return` clause?

Unreached expressions should have no effect. We can see a call expression:-

function unreachableExpression() {
   if(true) return;
   alert("Panic!!! I did not feature-test alert!");

}

And a return statement would also have no effect:-

function unreachableStatement() {
   if(true) return true;
   return false;

}

Each time that bind function is called, a new function is created, not
two. If arguments.length were 0, the second function expression would be
returned, but would always err because fn would be undefined. You
probably meant to check "if(arguments.length > 2)".

function f(){
   alert(this.type);

}

var e = bind(f, { sound: "elephant" });

The second function does not need the args property, so creating an
array would be unnecessary.

function bind(fn, context) {
   var args;
   if (arguments.length > 2) {
     args = Array.prototype.slice.call(arguments, 2);
     return function() {
       fn.apply(context, args);
     }
   }
   return function() {
     return fn.call(context);
   }

}

Thanks, Garrett.
That makes much sense.

So, as far as I understand, function expression in "unreached" block
is no different than any other expression in "unreached" block (in a
sense that it shouldn't be executed and so shouldn't allocate any
memory). Does spec actually define such behavior (object
initialization) or is it left up to an implementation?

Yes, it is defined in the specs, which you should be read at least
once.
.

Relevant Pages

  • Re: Godel proved maths inconsistent not incompleteness theorem
    ... proof checker for ZF, PA or what have you would be to implement some ... elementary pattern matching routines for the axioms/schemas of your ...   a. ... tell how big a task is until you spec it out. ...
    (sci.logic)
  • Re: Open Sound Control
    ... 32bit int)) will not work with the OSC spec. ...   - indexing pass, scan this list one variable-length thing at a time, ... The 1 to 4 nulls is the correct spec for strings, ...
    (comp.lang.tcl)
  • Re: Zoom H2 Handy Recorder - Brilliant!
    ... a device say its "USB 2" means nothing without it also saying what mode ...     USB2.0 Full-Speed compatible ... And the USB 2 spec says... ...
    (rec.audio.pro)
Loading