Confirmed users
346
edits
MemoryProfiler: Difference between revisions
Update the current status of memory-profiler project
(Created page with "This page describes the idea of the memory profiler that focuses on the memory footprints of execution flows. == Objectives == Traditional memory analysis tools look at the d...") |
(Update the current status of memory-profiler project) |
||
| (9 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
This page describes the idea of | This page describes the idea of a profiler that focuses on the memory footprints of execution flows. | ||
== Objectives == | == Objectives == | ||
| Line 6: | Line 6: | ||
Another common approach is to plot the allocations or the memory usages along the timeline. This gives some intuition of how and when a bulk of objects are allocated. However, it still relies on developers' wisdom, and sometimes chances, to dig out the problematical code snippet. | Another common approach is to plot the allocations or the memory usages along the timeline. This gives some intuition of how and when a bulk of objects are allocated. However, it still relies on developers' wisdom, and sometimes chances, to dig out the problematical code snippet. | ||
This memory profiler is designed to solve the inconveniences and limitations. The goal is to identify the memory eager codes directly. For example, it can show which functions | This memory profiler is designed to solve the inconveniences and limitations. The goal is to identify the memory eager codes directly. For example, it can show which functions retaining most: | ||
SelfSize TotalSize Name | SelfSize TotalSize Name | ||
| Line 17: | Line 17: | ||
851968 851968 t/t.prototype._create (https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:12) | 851968 851968 t/t.prototype._create (https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:12) | ||
or having | or having highest peaks: | ||
SelfHWM TotalHWM Name | SelfHWM TotalHWM Name | ||
| Line 29: | Line 29: | ||
1507328 1507328 PresShell::DoReflow | 1507328 1507328 PresShell::DoReflow | ||
1507328 13500416 p/<.run/x/< (https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:8) | 1507328 13500416 p/<.run/x/< (https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:8) | ||
== Contributing == | |||
The memory profiler code has been landed in mozilla-central. The user interface has been developed as an add-on hosted on Github. Your contributions is welcome. Open pull request directly or send questions to [http://mailto:dev-platform@lists.mozilla.org dev-platform@lists.mozilla.org]. | |||
* Addon: https://github.com/profiler-tools/memprof-addon | |||
== The Design == | == The Design == | ||
| Line 35: | Line 40: | ||
These sampled events can be used to approximate the full history of allocations afterwards. That means we can get various memory profiles of a program in different perspectives by post-processing the history in different ways. | These sampled events can be used to approximate the full history of allocations afterwards. That means we can get various memory profiles of a program in different perspectives by post-processing the history in different ways. | ||
The profiler is designed at the very beginning to support not only JavaScript but also native codes. Naturally, not only JavaScript objects but also native allocations are tracked. | |||
== Applications == | == Applications == | ||
Besides the two examples showing the functions retaining most and having highest peak, it can be used to find out functions, code snippets or call paths allocating most. | Besides the two examples showing the functions retaining most and having highest peak, it can be used to find out functions, code snippets or call paths allocating most. | ||
| Line 42: | Line 48: | ||
With the help of the timestamp, a size-time map can be plotted, too. | With the help of the timestamp, a size-time map can be plotted, too. | ||
== | == Features == | ||
The profiler is composed of two parts: the sampling engine and the front-end. Currently most of the efforts are devoted to the back-end and only a few JavaScript examples (quite useful but less convenient than you would expect) is available to give access to the profiler. | The profiler is composed of two parts: the sampling engine and the front-end. Currently most of the efforts are devoted to the back-end and only a few JavaScript examples (quite useful but less convenient than you would expect) is available to give access to the profiler. | ||
The profiler will be able to | |||
* Provide a way to start/stop | |||
* A timeline that: | |||
** shows the overall memory usage history | |||
** allows zooming into a time interval for the following views | |||
* A rank-list view that shows top functions that are most memory eager | |||
** 6 measurements: {retained, allocated, peak} x {self, inclusive} | |||
* A tree view that shows functions as call trees | |||
** 6 measurements: {retained, allocated, peak} x {self, inclusive} | |||
* A filter to focus on interested functions | |||
** Click item in rank list view or tree view, when item is clicked | |||
*** Show traces related to item in rank-list view | |||
*** Highlight related path in tree view | |||
== Work in Progress == | |||
=== Meta Bug === | |||
<bugzilla> | |||
{ | |||
"id": "1059139" | |||
} | |||
</bugzilla> | |||
=== Dependencies === | |||
<bugzilla> | |||
{ | |||
"f1": "blocked", | |||
"o1": "anywords", | |||
"v1": "1059139", | |||
"include_fields": "id, summary, whiteboard, keywords, assigned_to, status" | |||
} | |||
</bugzilla> | |||
== Terminology == | |||
* trace: denote a complete call tree from root to leave items. A profiling result may end with several traces. | |||
* item: each element in a trace is an item. | |||
== User Interface == | |||
[[File:Mockup-2.png|640px]] | |||