perf(Angular): only create new collection in getBlockNodes if the block has changed

[jbedard]

Doing something such as...

var scope = $rootScope.$new();
$compile( $('<div ng-if="i"></div>').appendTo('body') )(scope);
while (loop forever) {
   scope.i = (0 === ++i%2);
   scope.digest()
}

The getBlockNodes goes from about 2.5% => 0.25%. In any real test that diff would probably round down to zero though. But for only 3 extra lines (2 being }) I thought I'd at least throw it out there...

[lgalfaso]

There is something I do not fin 100% satisfactory with the patch, but I am not sure exactly what it is... Why not just

// warning untested code
var node = nodes[0];
var endNode = nodes[nodes.length - 1];
var i = 1;
do {
  node = node.nextSibling;
  if (!node) break;
  nodes[i++] = node;
} while (node !== endNode);
nodes.length = i;
return nodes;

?

[jbedard]

I agree the existing patch is a little weird (something to do with the happens-once-if within a loop?).

I think by modifying the original (like your snippet) it may have broke some use cases but I'd have to double check that. I think the array entries after the new length also need to be cleared. I'll give it a shot when I have a chance.

[jbedard]

Modifying the passed in array/jqlite object causes some tests to fail, I haven't really figured out why. I think that's why I originally didn't do that and left that part of the TODO in there.

[caitp]

what do we actually use getBlockNodes() for? grepping...

[caitp]

I guess it's used by some element transclusion directives, alright

[jbedard]

I believe its main purpose is to pickup DOM updates such as nodes being added/removed between the ng-if/repeat start/end nodes. So in most cases there should be no changes.

[jbedard]

I've rebased and updated this a bit to make it less awkward (imo). I'm fine just closing this if no one is interested though... (see jbedard@77f0881 for the old one that I think is more awkward).