Summit2008/Sessions/Proposals/Platform/WebPerformanceTools: Difference between revisions
(New page: ; Title : Performance and Memory Tools for the Web Platform ; Leader : David Baron == Summary == As developers of a complex C++ application, we often want to improve the speed or the mem...) |
(→Agenda) |
||
Line 19: | Line 19: | ||
* Discuss implementation approaches for memory usage analysis tools | * Discuss implementation approaches for memory usage analysis tools | ||
** in-process or out-of-process? | ** in-process or out-of-process? | ||
== Thoughts on requirements == | |||
* ability to categorize memory usage by frame/page/site and by type of allocation (images, JS, DOM nodes, etc.) [dbaron] | |||
* standard profiling UI for JS [dbaron] | |||
* profiling UI that can explain time spent on things like style resolution, layout, etc., relative to what nodes are being laid out (and what JS triggered that work, even if it was asynchronous) [dbaron] | |||
* profiling UI that can highlight thrashing caused by functions requiring flushes [dbaron] | |||
* profiling UI that can highlight the problems that are causing the event queue not to be serviced for a long time (i.e., show the performance problems in the longest events) [dbaron] |
Revision as of 03:07, 14 June 2008
- Title
- Performance and Memory Tools for the Web Platform
- Leader
- David Baron
Summary
As developers of a complex C++ application, we often want to improve the speed or the memory usage of our application. We rely on various tools to measure aspects of performance and memory usage so that we know where to focus our efforts at improvement. As Web developers develop increasingly complex applications on the Web, we need to provide them with the equivalent tools so that they can understand and improve the speed and the memory usage of their applications, and so they can provide better feedback to us about performance and memory usage problems within the platform.
Building these tools would also provide infrastructure useful for users who want to answer questions like "Why is Firefox using so much memory right now?" or "Which of the 20 tabs I have open is making Firefox slow?". Giving users the ability to answer these questions will also put some additional pressure on Web authors to write applications efficiently.
Agenda
- Discuss requirements for performance and memory usage tools
- what they should be able to do?
- which requirements are more important?
- how big of a barrier to entry is acceptable for using these tools? (e.g., downloading a separate build? downloading debug symbols?)
- Discuss implementation approaches for performance analysis tools
- Discuss implementation approaches for memory usage analysis tools
- in-process or out-of-process?
Thoughts on requirements
- ability to categorize memory usage by frame/page/site and by type of allocation (images, JS, DOM nodes, etc.) [dbaron]
- standard profiling UI for JS [dbaron]
- profiling UI that can explain time spent on things like style resolution, layout, etc., relative to what nodes are being laid out (and what JS triggered that work, even if it was asynchronous) [dbaron]
- profiling UI that can highlight thrashing caused by functions requiring flushes [dbaron]
- profiling UI that can highlight the problems that are causing the event queue not to be serviced for a long time (i.e., show the performance problems in the longest events) [dbaron]