This looks interesting, would it be possible to get some numbers to know if there are any performance implications?

Seems to make no difference when running $compile("<div ng-if='true'></div>") in a loop. Although if I take out the if (removeCount === 1) case it is a couple percent slower.

There are other things in this method that can be changed if we want to speed it up though (see #9365).

@jbedard can you also try the performance on the case where multiple elements would need to be replaced?

What remains at #9365, I think it would be best if they can be split into more PRs (it you think that only one PR would be needed, then just rebase it once this lands)

Multiple elements seems to have the same result as removing the if (removeCount === 1) case for single elements - it is a couple percent slower and a fraction of a percent more memory (because splice returns a new array, I assume).

If you profile only the code changed on its own (indexOf+splice vs the loop) the loop one is 1-2x faster. But compared to the document fragment and data calls in this method this is insignificant.

Think it's worth removing that loop?

I would leave it as it... maybe just

diff --git a/src/ng/compile.js b/src/ng/compile.js
index 3de0d53..f582206 100644
--- a/src/ng/compile.js
+++ b/src/ng/compile.js
@@ -2424,12 +2424,8 @@ function $CompileProvider($provide, $$sanitizeUriProvider) {
             $rootElement[i++] = newNode;
             for (var j = i, j2 = j + removeCount - 1,
                      jj = $rootElement.length;
-                 j < jj; j++, j2++) {
-              if (j2 < jj) {
-                $rootElement[j] = $rootElement[j2];
-              } else {
-                delete $rootElement[j];
-              }
+                 j2 < jj; j++, j2++) {
+              $rootElement[j] = $rootElement[j2];
             }
             $rootElement.length -= removeCount - 1;

I still think this is worth removing that ugly loop, but feel free to close it if you disagree. Note that your snippet above won't work (I think...) because these are (always? often?) jqLite objects and not arrays so the delete is needed in addition to the length change...

I'm going through old jqLite-related issues/PRs. What's the state of this one? Is it still worth landing, @jbedard?

I still think this makes things prettier, but others seemed to disagree. I'm fine closing it...

Looks like this won't happen, closing.