Save some CPU calculations

[mauroc8]

Q	A
Bug fix?	no
New feature?	no
BC breaks?	no
Deprecations?	no
New tests added?	not needed
Fixed tickets
License	MIT

Description

I just made the code more simple. It works exactly the same but now it's more readable, and the cpu has to make fewer calculations.

Let's compare:

textIndexOfEndOfFarthestNode = currentTextIndex + (newNode || currentNode).nodeValue.length +
    (newNode ? currentNode.nodeValue.length : 0) -
    1;

If newNode is defined, then it resolves to:

textIndexOfEndOfFarthestNode = currentTextIndex + newNode.nodeValue.length +
    currentNode.nodeValue.length - 1;

If newNode is undefined, it resolves to:

textIndexOfEndOfFarthestNode = currentTextIndex + currentNode.nodeValue.length - 1;

Then, it is more readable to write it like this:

textIndexOfEndOfFarthestNode = currentTextIndex + currentNode.nodeValue.length +
    (newNode ? newNode.nodeValue.length : 0) - 1;

---

Then there's the other line:

endSplitPoint = (newNode || currentNode).nodeValue.length -
    (textIndexOfEndOfFarthestNode + 1 - matchEndIndex);

Let's break it. When newNode is defined, it resolves to:

endSplitPoint = newNode.nodeValue.length -
    (textIndexOfEndOfFarthestNode + 1 - matchEndIndex);

Which is equivalent to:

endSplitPoint = newNode.nodeValue.length -
    textIndexOfEndOfFarthestNode - 1 + matchEndIndex;

Now, when newNode is defined, textIndexOfEndOfFarthestNode will be equal to currentTextIndex + currentNode.nodeValue.length + newNode.nodeValue.length - 1;

So we replace:

endSplitPoint = newNode.nodeValue.length -
    (currentTextIndex + currentNode.nodeValue.length + newNode.nodeValue.length - 1) -
    1 + matchEndIndex;

We remove parenthesis:

endSplitPoint = newNode.nodeValue.length - currentTextIndex -
    currentNode.nodeValue.length - newNode.nodeValue.length + 1
    - 1 + matchEndIndex;

We can simplify because we have newNode.nodeValue.length - newNode.nodeValue.length and 1 - 1, which both equal to 0.

 endSplitPoint = - currentTextIndex - currentNode.nodeValue.length +
     matchEndIndex;

Finally, we rearrange the elements.

endSplitPoint = matchEndIndex - currentTextIndex -
    currentNode.nodeValue.length;

What if newNode is undefined?

endSplitPoint = currentNode.nodeValue.length -
                (textIndexOfEndOfFarthestNode + 1 - matchEndIndex);

endSplitPoint = currentNode.nodeValue.length -
    textIndexOfEndOfFarthestNode - 1 + matchEndIndex;

Now textIndexOfEndOfFarthestNode will be currentTextIndex + currentNode.nodeValue.length - 1.

endSplitPoint = currentNode.nodeValue.length -
    (currentTextIndex + currentNode.nodeValue.length - 1) - 1 + matchEndIndex;

endSplitPoint = currentNode.nodeValue.length -
    currentTextIndex - currentNode.nodeValue.length + 1 -
    1 + matchEndIndex;

And simplifying we got:

endSplitPoint = matchEndIndex - currentTextIndex;

So, endSplitPoint can be defined as:

endSplitPoint = matchEndIndex - currentTextIndex -
    (newNode ? currentNode.nodeValue.length : 0);

---

If you think about it, you'll be able to understand it's logic. It is not an essential change. It only makes things slightly more simple and avoids headaches when trying to understand. It also makes it easier for the CPU.

[coveralls]

Changes Unknown when pulling 627c0b6 on mauroc8:master into ** on yabwe:master**.

[j0k3r]

Thanks for that big explanation !