View source for Performance:Footprint Tools

= Goal =

Here are the goals of that these brownbags are trying to achieve in order of priority.

# Reduce footprint of embeddable engine and netscape browser
# Reduce pageload time
# Reduce new window open time
# Reduce startup time

= What do engineers want from these brownbags ? =

# Tools - Measurement and Analysis
# Patterns to fixing the areas found

This is corresponds closely to the performance/footprint improvement loop : measure -> analyze -> fix -> measure

= Footprint : What is it ? Why is it important ? =

The amount of memory we allocate and keep is footprint, the operative word being keep. We do a lot of allocs and frees like for strings across api boundaries. But those are a performance problem rather than a footprint issue.

Footprint is important because this precludes us from running on smaller machines or machines with lesser memory. Also most reducing footprint will reduce performance - we wont allocate that much meaning we wont spend the time to allocate that much. Yes, The caveat there is sometime the extra allocation are for reducing performance. My only advice is measure dont assume! (See Patterns for resolving space-time conflict)

= Interesting Statistics =

* Browser footprint
**  7.8MB startup
** 11.5MB after page-load test
** 18.5MB after bookmarks
** 21.8MB after mail compose
** 28MB after main window
* 60% of total bytes allocated are from less than 128 byte allocations
** 1-16 byte allocations account for 485,472 bytes, or 7%.
** 17-32 byte allocations account for 1,224,608 bytes, or 19%
** 33-128 byte allocations account for 2,802,144 bytes, or 43%
* 2MB allocated by children of XULContentSinkImpl members
* 374k allocated by 258 PL_ArenaAllocate call
*  95k allocated by children of PREF_Init
*  84k result of NS_NewAtom

= Measurement and Analysis Tools =

Test cases:

* Startup w/about:blank and keep it alive for about 10 secs
* Load your page of interest and keep it up for 10 secs
* do your operation of interest like loading preferences or selection

The keep it alive for 10 secs is for Space Trace - it by default ignores all allocations that live for less than 10 secs.

Tools for Measurement and Analysis are:

# Bloat Tinderbox (MH value)- Gives an overall bloat number of total memory consumed. Dont trust any other bloat number that appears on tinderbox for tracking footprint. Only the new style tinderboxes give a good estimate of footprint. http://www.mozilla.org/performance/leak-brownbag.html#new-tbox
# Look at task manager on windows or top on unix (mac?) to see total memory consumed at a given time. On windows, remember to iconify and show the window before you read the memory usage from the task manager.
# BloatView - Trust only the number of object created of a particular type http://lxr.mozilla.org/mozilla/source/xpcom/doc/MemoryTools.html
#:  set XPCOM_MEM_BLOAT_LOG=1  (run time)
# Space Trace - http://mozilla.org/projects/footprint/spaceTrace.html
      TraceMalloc based query tool for individual allocations and how long they lived. Written by Garrett Blythe <blythe@netscape.com>

= Patterns of fixing the areas found =

# Reduce data structure / object sizes
#* Promote unused members of frequently used objects into parent/owner of object as lists (space/time tradeoff). E.g DOM
#* vtable does take 1 word (4 bytes) per direct interface
#* Alignment - word align members of objects. A simple rule of thumb is keep variables of same type together.
#* delay load/create
# Focus on objects created many times and held longer ( Space Trace )
# space / time tradeoff - Ways for handling them could be
* build time switch
* preference based switch
The hard this hear is going to be keeping them bitrotting. 

= Checklist =

# Focus on objects that are allocated many times and long lived.
# Any improvement of over 1k is good