You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Proposal: Introduce codemod tools for long-term refactoring works #38609
Can't say it saves lots of time in this case, because there are not many changes. But it may be useful in the future, especially as the codebase grows.
This could be very helpful but the problem is that in some cases, primordials cause significant regressions. Until we have optimisations from V8, we cannot have a blanket implementation of primordials.
We already have some instances where we had to revert the use of primordials to deal with significant regressions.
See #38248 and #38246
I'm also -1 on codemods for primordials (I'm ±0 in general, depending on the use-case I guess), as we've seen that they create performance issues and they shouldn't be added without some thought, and at least some benchmarking.
Maybe we can find which primoridials are good to perf. with tools by choosing subset of promoridials to refactor?
I assume that static function primordials are probably relatively safe (MathMax etc.), however others probably less so. IIRC Array methods were especially problematic, as were FunctionApply etc.
Even so, maybe even for static functions, it might be hard to see before-hand how stuff would hurt inlining (e.g. #38246 (comment)) and if there's actually a good general rule for changing stuff.
Reacted by Benjamin Gruenbaum and Ruben Bridgewater
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Activity
marsonya commentedon May 10, 2021
This could be very helpful but the problem is that in some cases, primordials cause significant regressions. Until we have optimisations from V8, we cannot have a blanket implementation of primordials.
We already have some instances where we had to revert the use of primordials to deal with significant regressions.
See #38248 and #38246
Ayase-252 commentedon May 10, 2021
Maybe we can find which primoridials are good to perf. with tools by choosing subset of promoridials to refactor?
Linkgoron commentedon May 10, 2021
I'm also -1 on codemods for primordials (I'm ±0 in general, depending on the use-case I guess), as we've seen that they create performance issues and they shouldn't be added without some thought, and at least some benchmarking.
I assume that static function primordials are probably relatively safe (MathMax etc.), however others probably less so. IIRC Array methods were especially problematic, as were FunctionApply etc.
Even so, maybe even for static functions, it might be hard to see before-hand how stuff would hurt inlining (e.g. #38246 (comment)) and if there's actually a good general rule for changing stuff.
bmeck commentedon May 10, 2021
We could probably at least do codemods to automate generating out code gen traces like we did with https://bugs.chromium.org/p/v8/issues/detail?id=9702&q=bound%20apply&can=1 to check for regressions rather than doing it manually and then open up any issues upstream
avivkeller commentedon Jul 11, 2024
Hey, is this still being worked on? If not, feel-free to self-close the issue?
github-actions commentedon Jun 27, 2026
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
github-actions commentedon Jul 28, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.