perf: replace endsWith with ===

[sun0day]

Description

Similar to #12531, this PR uses === instead of endsWith in some hot extensions.

Additional context

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[bluwy]

I'm not sure about this. I'd prefer if it indexes one char only, when searching longer words I think endsWith or startsWith is the right tool for it.

[patak-dev]

Did you measure the perf diff on this one @sun0day? I also think that this is going too far. I think we better keep using endsWidth here.

[sun0day]

I only tested the js code performance between str.endsWith and str[len-1] === 'x' && str[len-2]==='y', I haven't tested in a real app since I didn't find a proper one.

The thing is that plain === is 60%-70% faster than endsWith in the js perf test. It's really an attractive number. I am not gonna replace all the endsWith in the codebase but replace some hot extensions' judgment.

But also I know that endsWith is not the bottleneck and it may only improve a little perf even if replace all the endsWith in the real app. I am fine with indexing one char only

[bluwy]

Looking forward to the next major where we can use String.prototype.at to make these more compact.

[robpalme]

Thank you for identifying this performance issue. I have reported it to the V8 project.

[patak-dev]

Thanks @robpalme 🙏🏼