24
edits
DevTools/Planning/Performance/Details: Difference between revisions
Request to delete old information
(Request to delete old information) |
|||
| (8 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{delete|This information is very outdated, please see profiler.firefox.com for the current profiling infrastructure.|date=05/27/2020}} | |||
===Performance Overview=== | ===Performance Overview=== | ||
To optimize the performance of an html5 and JS based web application, we need | To optimize the performance of an html5 and JS based web application, we need two general pieces of information, each of which requires slightly different tooling, or a universal tool that can do both: | ||
'''1) What's slowing down execution'''<br> | '''1) What's slowing down execution'''<br> | ||
| Line 27: | Line 29: | ||
That's about it, and it should not be more complicated than that. | That's about it, and it should not be more complicated than that. | ||
===Proposed "memory leak timeline" design=== | |||
<ul> | |||
<li>Objects are grouped: examples include grouping by various object roots, by event handlers, by DOM, and by constructors. | |||
<li>Each group has a horizontal timeline where creation of objects is represented by a color with an intensity proportional to the number of objects created per unit of time (usually a frame), and another color and intensity is represented for GC'd objects. | |||
<li>On the right is a detailed count summary for the group. | |||
<li>Since we can't tell how many objects are really in use, but we can only count with respect to time, we pick a "null time bookmark" which defaults to the far left of the timeline but can be moved by the user if desired. (Important for dynamic recording.) (It would also be nice to have a "reload" marker so that the user can choose to reload the page and get an exact count relative to the reload event.) | |||
<li>Two sliders can be used to depict object sizes. If both are selected, the diff is shown, if only one is selected, total# is shown with respect to null time bookmark. | |||
<li>Detailed view below the timeline shows the object list and associated object tree with the selected object grouping (usually a type of root.) | |||
</ul> | |||
<p> | |||
[[Image:MemoryView.png|center|thumb|980px]] | |||
</p> | |||
===Product Design Challenges=== | ===Product Design Challenges=== | ||
| Line 35: | Line 52: | ||
'''1) Flame Charting'''<br> | '''1) Flame Charting'''<br> | ||
Flame charts are intuitive ways of representing both time-based and memory-based recordings and for representing live memory feedback. there should be a unified way to navigate across flame charts and clicking through the elements. | Flame charts are intuitive ways of representing both time-based and memory-based recordings and for representing live memory feedback. there should be a unified way to navigate across flame charts and clicking through the elements. | ||
''' | |||
2) Cycling between live visualization and recording mode'''<br> | '''2) Cycling between live visualization and recording mode'''<br> | ||
In order to find problems, engineers need to be able to interact with their applications. It's not easy to go back into a recording and find problems if you forgot what you did when you recorded. So there is a need to provide live feedback, allow for a deeper dive, and, finally perhaps to pass over and record with deeper instrumentation. One possible concept is to allow for a combo live feedback and keep at least 15 seconds of recording in memory so that if the user sees a problem, he can hit a sort of "pause" button that would allow him to look at the last 15 seconds and see more details. Of course, this is not an issue while actually recording, but live feedback should always come with at least 5-15 seconds of "buffer" so that one can go back and look at what happened when say live frame rate feedback suggests a slow down. | In order to find problems, engineers need to be able to interact with their applications. It's not easy to go back into a recording and find problems if you forgot what you did when you recorded. So there is a need to provide live feedback, allow for a deeper dive, and, finally perhaps to pass over and record with deeper instrumentation. One possible concept is to allow for a combo live feedback and keep at least 15 seconds of recording in memory so that if the user sees a problem, he can hit a sort of "pause" button that would allow him to look at the last 15 seconds and see more details. Of course, this is not an issue while actually recording, but live feedback should always come with at least 5-15 seconds of "buffer" so that one can go back and look at what happened when say live frame rate feedback suggests a slow down. | ||
'''3) One single recording tool as opposed to distinct recording tools'''<br> | '''3) One single recording tool as opposed to distinct recording tools'''<br> | ||
Does a developer really need to figure out whether to do a "timeline" or a "CPU profile" or a "whatever profile?". Isn't it enough to have one recording UI that provides a container for any "type" of recording? In reality, there is only one recording but with different depths of instrumentation. This does pose a challenge: how to have a combined temporal and memory based view. My gut tells me this is doable, we will just need to find an easy, user friendly way of doing it. | Does a developer really need to figure out whether to do a "timeline" or a "CPU profile" or a "whatever profile?". Isn't it enough to have one recording UI that provides a container for any "type" of recording? In reality, there is only one recording but with different depths of instrumentation. This does pose a challenge: how to have a combined temporal and memory based view. My gut tells me this is doable, we will just need to find an easy, user friendly way of doing it. | ||
<ul> | |||
<li>Timeline layers is one way to give us the ability to correlate different timelines on top of each other. | |||
<li>Each layer can be turned on or off and it would turn on or off the respective instrumentation. | |||
</ul> | |||
'''4) Changing sampling/instrumentation depth'''<br> | '''4) Changing sampling/instrumentation depth'''<br> | ||