DevTools/Planning/Performance/Details: Difference between revisions
(Created page with "===Performance Overview=== To optimize the performance of an html5 and JS based web application, we need three general pieces of information, each of which requires slightly...") |
No edit summary |
||
| Line 12: | Line 12: | ||
<li>e) Unoptimized garbage collection: if we keep releasing a lot of objects, GC will run more frequently | <li>e) Unoptimized garbage collection: if we keep releasing a lot of objects, GC will run more frequently | ||
</ul> | </ul> | ||
The right tooling will instrument as lightly as possible in order to minimize impact on performance and will provide a time-based view of execution. | The right tooling will instrument as lightly as possible in order to minimize impact on performance and will provide a time-based view of execution. Mostly, as a developer, I want to find out where my application is slowing down (frame rate) and why (where is my application spending time when the frame rate slows down.) | ||
'''2) What's increasing memory consumption'''<br> | '''2) What's increasing memory consumption'''<br> | ||
When the browser was king, web apps could run on desktops and laptops where memory was really not much of a consideration, especially when it came to writing client-side apps. But with the proliferation of mobile devices and the push towards cheaper devices, memory is a premium and can no longer be taken for granted. Hence there is a need for tools that can tell us about our application's memory consumption and clues on how to minimize it. | |||
In general, optimizing memory is really about counting object instances. There are several different types of memory optimizations that need to be done: | |||
<ul> | |||
<li>Short term memory leaks (Google calls this "scattered objects" or "Action cleanness".) | |||
<li>DOM Leaks, i.e. Orphaned DOM fragments that keep increasing after specific events | |||
<li>Long term memory leaks, i.e. less obvious leaks that take 5 minutes or more to increase to a measurable level. | |||
</ul> | |||
===Product Design Challenges=== | |||
Memory and application | |||
Revision as of 02:54, 6 November 2013
Performance Overview
To optimize the performance of an html5 and JS based web application, we need three general pieces of information, each of which requires slightly different tools:
1) What's slowing down execution
What it really comes down to is how well the application responds and flows. So we are basically looking for slowdowns in frame rates and looking for the root causes of those slow downs. Those root causes generally come from three sources:
- a) Excessive DOM and graphical changes coming from JS execution
- b) Excessive DOM and graphical changes coming from unoptimized HTML5 and CSS
- c) Unoptimized JS code itself, i.e. the code just takes too long to run
- d) Unoptimized JS execution (baseline versus ionmonkey)
- e) Unoptimized garbage collection: if we keep releasing a lot of objects, GC will run more frequently
The right tooling will instrument as lightly as possible in order to minimize impact on performance and will provide a time-based view of execution. Mostly, as a developer, I want to find out where my application is slowing down (frame rate) and why (where is my application spending time when the frame rate slows down.)
2) What's increasing memory consumption
When the browser was king, web apps could run on desktops and laptops where memory was really not much of a consideration, especially when it came to writing client-side apps. But with the proliferation of mobile devices and the push towards cheaper devices, memory is a premium and can no longer be taken for granted. Hence there is a need for tools that can tell us about our application's memory consumption and clues on how to minimize it.
In general, optimizing memory is really about counting object instances. There are several different types of memory optimizations that need to be done:
- Short term memory leaks (Google calls this "scattered objects" or "Action cleanness".)
- DOM Leaks, i.e. Orphaned DOM fragments that keep increasing after specific events
- Long term memory leaks, i.e. less obvious leaks that take 5 minutes or more to increase to a measurable level.
Product Design Challenges
Memory and application