refactor: restore endsWith usage

[OnlyWick]

Description

refs: #12539 (comment)

[bluwy]

Could we also compare the performance first with https://perf.link or a local script to double-confirm that it's fixed now?

[OnlyWick]

Try this!

const data = "abcdefg";

const total = 100000;

let start = performance.now();
for (let i = 0; i < total; i++) {
  data[data.length - 1] === "a";
}
console.log("index", performance.now() - start);

start = performance.now();
for (let i = 0; i < total; i++) {
  data.endsWith("a");
}
console.log("endsWith", performance.now() - start);

Node.js v18

[OnlyWick]

I have tested in Node.js V12, endsWith is still faster than index accessor.

After testing in the browser, the performance difference between endsWith and the index accessor has indeed become smaller, Moreover, the performance of startsWith and endsWith may even be better. Additionally, aren't we in a Node.js environment? Perhaps we can ignore the differences in the browser?

endsWith VS index accessor

startsWith VS index accessor

Note: You need to RUN the tests multiple times to see the difference. Now they basically have little performance difference. Sometimes the index accessor is faster, sometimes starts/endsWith is faster.

But, if you run the test code I wrote in the Chrome console, index accessor will be faster. Could it be that there are some additional things being executed in the browser console that affect this?

[bluwy]

I think the perf test should use a benchmarking tool to properly measure it, as I'm able to reproduce the slower perf for endsWith before. Node v18 is also using an older version of v8 which doesn't include the fix linked. Using node v22 would include the fix. I've adapted your benchmark like so:

import { bench, do_not_optimize, run } from 'mitata'

const data = 'abcdefg'

bench('index', function* () {
  yield () => do_not_optimize(data[data.length - 1] === 'a')
})

bench('endsWith', function* () {
  yield () => do_not_optimize(data.endsWith('a'))
})

run()

Node 18	Node 22

So it does show that endsWith is now close to and sometimes faster than index now. Using the browser should yield similar results as we're mainly testing v8.

I was curious of a comparison as the chromium issue mentioned that they optimized endsWith the same way as startsWith, so theoretically [0] is still faster than startsWith which we changed in the past. And it seems to still be true:

Node 18	Node 22

So we may want to still stick with [0]. (Though personally I think these micro-optimizations aren't necessarily something we have to stick to forever)