Performance on startup

23 views
Skip to first unread message

Tim Van der Lippe

unread,
Oct 29, 2021, 12:10:52 PM10/29/21
to devtools-dev
Hey Microsoft/DevTools folks,

In the past week, I have been working on removing more module.json files that are effectively no-ops. These files were causing additional fetch requests to `<folder>_module.js` files, which we suspect were reducing performance on startup.

Can you please rerun your numbers and share with us if the work here has indeed mitigated the impact on startup that you reported on before? If not, do you have any suggestions as to where we should be investigating, ideally with numbers that we can analyze and further pinpoint the culprit?

Cheers,
Tim

Zoher Ghadyali

unread,
Nov 3, 2021, 2:09:24 PM11/3/21
to Tim Van der Lippe, devtools-dev
Hi Tim,

Thanks for reaching out! I'm happy to report that we are seeing a ~100ms improvement in launch time for the Elements tool as a result of your change. This is a fantastic improvement. However, I also want to clarify that this improvement accounts for 1/6 of the overall regression we're seeing of 600ms in launch time for Chromium DevTools.

In August and September of 2020, we were reporting ~1000ms for launching the Elements tool. As of August 2021, we were reporting ~1600ms. With your change in October 2021, we're now reporting ~1450-1500ms in launch time. Because of the amount of refactoring that's happened in DevTools and the year between August 2020 and August 2021 where we've seen a slowly increasing regression in DevTools launch time, it's practically impossible to identify a culprit commit. I think we're better served by making improvements to DevTools launch time and measuring their impact.

If you continue to make fixes and want to know their performance impact, I'm happy to share the numbers from our existing perf tests but you can also validate these numbers yourself against builds of Chromium by following the steps in this crbug: 1046596 - Move to ESM has introduced regression in DevTools performance - chromium. Your numbers on your dev machine or laptop won't be the same as ours because the underlying hardware is different but you should see similar trends, regressions, and improvements if you test Chromium builds from August 2020, August 2021, and now.

Let me know if there's anything else I can help with!

Thanks,
Zoher

--
You received this message because you are subscribed to the Google Groups "devtools-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devtools-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/devtools-dev/CAKCakL4sQRpLQC2MCZt6Nv2cvjEJWRyYwfuQ1Mu9KUAqamKPMA%40mail.gmail.com.

Tim Van der Lippe

unread,
Nov 5, 2021, 11:44:26 AM11/5/21
to Zoher Ghadyali, devtools-dev
Hello Zoher,

Thank you for your response! I am glad to hear the `module.json` removal is indeed making considerable improvements to our startup process. Based on that and previous findings, I am now fairly confident to say that DevTools startup is predominantly network request bound. E.g. the more files we load, the slower startup will be.

To that extent, I prepare a further CL to remove some more legacy files out of our main shell and into the legacy_test_runner: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3264212/ I am hopeful that this will also have a good impact on our startup performance. Since we are now fully using ES modules + TypeScript, our production bundle doesn't require these globals to exist anymore. We only need to carry them around for the layout tests, which means we only need to load them in `legacy_test_runner.ts`.

Test failures notwithstanding, I hope that we can submit that CL early next week. Do let me know if you observe a similar improvement to the ones before, to confirm the network request theory.

Cheers,
Tim
Reply all
Reply to author
Forward
0 new messages