-
Notifications
You must be signed in to change notification settings - Fork 424
refactor: remove cargo cult #5607
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
Conversation
not needed
|
Error while creating work item! |
|
/nucleus ignore --reason "Nah." |
|
⚠ The test stage has a status of running, which cannot be ignored. |
|
I'm unfortunately not going to be able to follow up on this question, but I was wondering if we know why the The other numbers look great, but the It looks like the regression is amortized and eventually offset as the tables get larger (as seen from the perf improvement on the All this to say the perf improvements look great, but the biggest gains seem to be with less common use cases and the biggest regression is potentially with one of the biggest (or most visible) use cases. We should validate what the impact might be on those end use cases. |
|
/nucleus ignore --reason "soon it shall be gone" |
Details
In our runtime packages, we have an established pattern of using detached prototype methods instead of writing normal code. As an example, we would replace
arr.push(value)withArrayPush.call(arr, value). There are two reasons cited for this. The first is security. Prototypes can be mutated, so users can theoretically change thepushthat we're calling to something that we don't expect. By taking a snapshot before executing any user code, we can avoid this. The second reason is performance. At some point, using detached methods may have been faster. But, when I removed them and ran the perf benchmarks, writing code the normal way was more than 20% faster for some of the benchmarks. Curiously, it is 20% slower for thecreate-rows-1kbenchmark. That is a relatively common use case (far more common than thecreate-rows-10kthat gets the best perf boost), so that alone may be enough to scuttle this idea.We also have a pattern of using utility functions like
isUndefined(x)instead of directly checkingx === undefined. This reduces file sizes (function calls can be minified tof(x); direct comparisons cannot) at the expense of performance (extra function call). A much more marginal change, but I still saw some improvement when I ran the perf benchmarks with this change on top of the prototype change.Benchmark results: no detached prototype
Benchmark results: no detached prototype + no util functions
Does this pull request introduce a breaking change?
Does this pull request introduce an observable change?
GUS work item