Issue #4376

This test-case is intended for Issue #4376 - Simple Memory Profiler.
Jan Odvarko, John J. Barton

This page implements several test cases, that demonstrate usage of Firebug's Memory Profiler for detecting memory leaks in a web application. You need at least Firebug 1.8a2 (or build from latest source) installed in your browser. Please post feedback in the newsgroup, thanks.

1. Memory allocation for images
2. Memory allocation for strings
3. Memory leak detection
4. Page load memory profiling

Case 1: Memory allocation for images

1. Open Firebug and enable the Console panel.
2. Click the Memory Profile button in the Console panel toolbar to start profiling.
3. Click the Load Image button below.
4. Click Memory Profile again to stop profiling.

• You should see Memory Profiler Results within the Console panel.
• The images/content/used/raw column shows the amount of memory allocated for images in this profiling session.
• Two functions have been called to load an image. onLoadImage represents the button's click handler and onload is a callback associated with the created Image object.
• The images/content/used/raw shows zero for these function calls, since the image load is asynchronous.
• The images/content/used/raw shows 29.3 KB for Entire Session. This corresponds to one loaded image. You can check this in the Net panel.
• Below the Memory Profiler Results you should see Objects Added While Profiling. If you open this list, you will see the images added. Of course these objects may or may not be leaks, depending on the purpose of the onLoadImage operation.

Case 2: Memory allocation for strings

1. Open Firebug and enable the Console panel.
2. Click the Memory Profile button in the Console panel toolbar to start profiling.
3. Click the Allocate Strings button below (0, 1 and N times).
4. Click Memory Profile again to stop profiling.

• Repeat the same test several times: don't click the button, click it once, click it e.g. 5 times.
• One function onAllocateString is called (if the button is clicked). It's the button's click handler.
• Compare the results in the js/string-data column.
• The more you're clicking the button, the more memory for strings is allocated.
• Some strings are allocated even if you don't click the Allocate Strings button at all. This is because some strings are allocated by Firebug itself (also JavaScript) during the profiling session (TODO: could we not include this?).
• Below the Memory Profiler Results you should see Objects Added While Profiling. If you open this list you, will see an array that has new entries from the onAllocateString operation. We currently don't track strings, individual array elements or anything specifically, so this list is really just a hint on what changed.

Case 3: Memory leak detection

1. Open Firebug and enable the Console panel.
2. Click the Memory Profile button in the Console panel toolbar to start profiling.
3. Select the Memory Leak On option below (should be by default).
4. Click the Create Some JS Objects button below.
5. Click Memory Profile again to stop profiling.

• You should see Objects Added While Profiling results in the Console panel.
• Repeat the same test with Memory Leak Off and compare results.
• Use the same test scenario but click the button below. This example represents a real world scenario with forgotten listeners (not beeing unregistered). Register Listeners

Case 4: Page load memory profiling

1. Open Firebug and enable the Console panel.
2. Click the Memory Profile button in the Console panel toolbar to start profiling.
3. Reload this page.
4. Click Memory Profile again to stop profiling.

• The profiling session begins automatially when the page load starts - till you click to stop it.
• This page calls click handlers for every test case above during the load phase.