-
-
Notifications
You must be signed in to change notification settings - Fork 89
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
Improve "apply" trap performance #48
Comments
Actually those methods don't need to be proxied in the first place, in my benchmarks this improves performance 10x. |
Actually some of those methods need to be proxied, as otherwise for example mutating an object retrieved via This is still a ~4x performance improvement according to my benchmarks though. |
Are you just whitelisting specific methods? Pull requests are welcome :) |
Essentially, yeah. Here's the list. I'm cutting corners a bit by not even checking what kind of objects have those methods, I'll see how that goes.
Thanks but as I basically ended up rewriting the entire thing (in hindsight I probably could have just forked this and submitted a bunch of PRs, but one of the main features I wanted my library to have in the end I couldn't implement) I won't really use |
Added in 2.1.0 |
I'm kind of rewriting this library to better suit my needs and I think I've found an interesting performance optimization.
Some methods of builtin objects can't mutate the object in question, like for instance calling
forEach
on an Array will never mutate the array, so we can avoid cloning, performing potentially expensive equality checks comparisons etc.This is assuming the prototype of Array doesn't get messed up with, but IMHO if somebody changes it in a way that non-mutating methods become mutating it's on them.
The text was updated successfully, but these errors were encountered: