perf(Angular): only create new collection in getBlockNodes if the block has changed#9899
perf(Angular): only create new collection in getBlockNodes if the block has changed#9899jbedard wants to merge 1 commit intoangular:masterfrom
Conversation
|
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;? |
|
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. |
|
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. |
|
what do we actually use |
|
I guess it's used by some element transclusion directives, alright |
|
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. |
77f0881 to
e317177
Compare
|
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). |
Doing something such as...
The
getBlockNodesgoes 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...