-
Notifications
You must be signed in to change notification settings - Fork 46.9k
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
Scheduling Profiler: Improve import performance by dropping IE support #19872
Conversation
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 5fc7cac:
|
} else { | ||
targets.chrome = minChromeVersion.toString(); | ||
targets.firefox = minFirefoxVersion.toString(); | ||
// We won't support IE because that'll double profile import times. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's unfortunate that we have to "support" IE for the case of RN, particularly if this results in less optimal compiled code. Maybe we can address this in a more wholistic way.
- I'll follow up with the Hermes team to see if this is still the best way to target Hermes for the standalone DevTools' embedded backend.
- I'll post a PR (shortly) that kills this target for everything except that standalone backend. (That seems better than leaving it on for everything except the scheduling profiler.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, thanks!
Thanks for digging in and identifying the cause of this perf problem, @taneliang! 🙇 |
Closing in favor of #19875 |
Summary
Resolves #19759 (comment) by forking the shared DevTools Babel config and disabling IE support. I think this should be okay for our standalone app, but we'll likely hit this perf issue again when this is merged into the main DevTools.
cc @bvaughn
Test Plan
Manually tested with our 57MB facebook.com profile.
Current https://react-scheduling-profiler.vercel.app/ (deployed from https://github.com/MLH-Fellowship/scheduling-profiler-prototype):
master
:This branch. It's about 5%-15% slower than https://react-scheduling-profiler.vercel.app/:
Alternate approach (b48ab94): reducing supported browsers to just
last 2 Chrome/Firefox versions
. This has a runtime similar to https://react-scheduling-profiler.vercel.app/: