Performance boost I assume?

@jasnell forgot to write about it. It is 2x faster on small strings, but is slower on large ones. This is the reason for awaiting for v8 update.

If the perf loss on the large ones is significant, perhaps split the difference and use the js method for short ones and fallback on longer?

Perhaps, but I'd rather wait for V8 update. We've been living with C++ code for awhile now.

Added expected V8 version.

Looks like this might be ready after #19201 lands.

Hm... it is still slow even on V8 6.6. cc @bmeurer

Here's the benchmark that I used: https://gist.github.com/indutny/0fe9a3ed3b93d558a60deacefc37e378 . The results are:

c++: 7.052ms
js: 6.731ms
c++: 235.835ms
js: 5739.299ms

You need to pass --nountrusted-code-mitigations to disable the Spectre mitigations, which also affect String#charCodeAt. But even then the C++ code is going to be significantly faster. I'm not sure we can fix the difference here.

@bmeurer tbh, I don't see a reason for it to be slow. The performance seems to be dependent on string flattening, which apparently doesn't happen in JS case. Could it potentially happen at all?

@indutny The reason is that String#charCodeAt() has to dispatch on string type all the time (potentially 8 different types for the "fast case"), whereas the C++ code just accesses the character data. We could try to make TurboFan a bit smarter here if we find a way to do the flattening (which is indeed happening here) in the peeled loop iteration only and then have only sequential one-byte string access inside the actual loop. But that's work that needs to be done and I'm a bit worried that we over-optimize for the particular example.

BTW V8 tip-of-tree should be faster already thanks to the recent work by @sigurdschneider.

@bmeurer thank you!

@jasnell and @nodejs/collaborators looks like it'd best to close this.

Not saying it's not worth it, but it's definitely not high priority.

Did you check with tip-of-tree? And --nountrusted-code-mitigations?

@bmeurer I checked --nountrusted-code-mitigations, and although it was faster - it was still significantly slower than C++. Didn't check tip-of-tree yet.

Should this stay open? It seems like the JS implementation can not get as fast as the C++ implementation. Ping @indutny

Closing as this does not seem like it is the right approach in JS.

@indutny please reopen in case you disagree and want to continue working on this.

I think we could potentially apply it to short strings. Anyone up to do some benchmarks?