Improve performance of _insertNodes

[filipsobol]

Suggested merge commit message (convention)

Other (engine): Improve performance of _insertNodes.

Other (utils): Change the implementation of spliceArray to modify the target array for better performance.

MINOR BREAKING CHANGE (utils): spliceArray now modifies the target array and doesn't accept a fourth (count) argument.

---

In #17456 I improved the performance of spliceArray. However, it turned out that it still does more than we need and because it's called often, we pay a price for it. This PR reduces the number of intermediate arrays we make whenever _insertNodes is called.

Below are the improvements (while on the remove-registerViewToModelLength branch, the percentages will be different on master)

Test name	Change in %	Change in ms
formattingLongP	-6.1	-260
inlineStyles	-7.9	-650
mixed	-5.0	-120
wiki	-4.3	-140

[scofalik]

How does the custom insertAt compare to native splice for parameters volume that does not crash splice?

Question two: maybe we could reimplement custom splice as what you proposed for insertAt?

[filipsobol]

How does the custom insertAt compare to native splice for parameters volume that does not crash splice?

Native .splice() is slower by about 25ms in inline-styles test.

Question two: maybe we could reimplement custom splice as what you proposed for insertAt?

This is the only place where the spliceArray helper was used, but it did not modify the original array. Changing its implementation would be a breaking change, which I want to avoid.

Also, in the first loop, is this direction like this because this way you change the targetArray length only once? If so, maybe it would be better to change the length before the loop and then go from the beginning to the end (for clarity purposes, it's easier to read).

Changing the array's length upfront is (surprisingly) much slower.

[scofalik]

Changing the array's length upfront is (surprisingly) much slower.

No comments.

How does the custom insertAt compare to native splice for parameters volume that does not crash splice?

Native .splice() is slower by about 25ms in inline-styles test.

Question two: maybe we could reimplement custom splice as what you proposed for insertAt?

This is the only place where the spliceArray helper was used, but it did not modify the original array. Changing its implementation would be a breaking change, which I want to avoid.

I am for replacing it and having this as minor breaking change. In general, people should not have a need to use spliceArray from our library even though it was available. Changing code from spliceArray() to insertAt() should be relatively easy. If anyone needs spliceArray() for some reason, they can even copy it from our code.