-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lib: Convert String#indexOf usages to String#includes #327
lib: Convert String#indexOf usages to String#includes #327
Conversation
do we have any perf data on |
It looks like it just calls |
From this test, it seems that |
|
Haven't looked into performance, but the code LGTM, FWIW. |
ftr, 👎 from me on this unless perf is improved. Same goes for most transitions to new V8 features in core, I'd expect them to remain unoptimised for some time just like many ES5 features ( |
While I appreciate the intent, I'm -1 on making this sort of change. I don't see any particular benefit in bulk-switching I'll leave this PR open until tomorrow evening to give other collaborators/TC members time to weigh in, but if no one chimes in before then I'll close it. |
fwiw, I'm with @rvagg; there's really no benefit of switching until performance at least is equal versus the benefit of readability. |
Closing this – |
I updated String.prototype.includes in V8 to be faster using ziyunfei's patch. I think this will come out around M46, but it's also an easy cherry-pick https://codereview.chromium.org/1231673008 . Performance is much closer now. Let me know if you have any other issues with the performance of this function. |
@littledan Nice! I left a couple of comments there. Please let me know what you think about them. |
@thefourtheye I committed the code as is. I don't think the things you pointed out would be performance issues. But thanks for taking a look. |
Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Vladimir de Turckheim <[email protected]> PR-URL: #315 Backport-PR-URL: #327 CVE-ID: CVE-2022-32215,CVE-2022-32214,CVE-2022-32213
No description provided.