From MozillaWiki
Jump to: navigation, search


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

  1. Reduce footprint of embeddable engine and netscape browser
  2. Reduce pageload time
  3. Reduce new window open time
  4. Reduce startup time

What do engineers want from these brownbags ?

  1. Measurement Tools and Techniques
  2. Analysis Tools and Techniques
  3. Patterns to fixing the areas found

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

Target Audience

Brownbag should be targeted at the average engineer. Little assumptions should be made about the knowledge of facilities such as c++, strings, xpcom etc. We should cover facilities and provide patterns that people can use as much as possible even if it is trivial.


(start with a New Created Profile)

Analysis Tools

Remember the simple things : printfs, #if 0 code and putting timers can go a long way.

  2. Quantify [windows]
    • Use optimized / MOZ_PROFILE build
    • Increase swap to atleast 500MB
    • Use Function level profiling
    • Command line arguments: -P 'Default User' file:///c|/tmp/quit.html
    • Focus subtree on main1
  3. jprof [linux]
  4. Simon Fraser is working on a graphical analysis tool for mac
  5. printfs
  6. #if 0 : a very useful method in easily finding out the cost associated with a #particular piece of code or feature
  7. mallocsites: Number of allocations
  8. BloatView - Number of objects created
  9. strace [linux] - view all system calls made by application

Current Performance Project Plan

Performance Theory

There are two approaches to fixing performance.

  • Eliminate the cost - most desirable
  • Reduce the cost - better algorithms, data structures, code

Evaluate if eliminating the cost, even conditionally, is possible before rushing to reduce the cost. E.g

E.g. International code was loading file on startup. This file contained a mapping of charsets to internal normalized form. It so happens that only a few charsets are encountered by a large % (like 90%) of our users. The fix that Frang Tang and Juraj Betak came with was to make an internal table of those frequently used 5 charsets and load the file only if a charset outside of this list if encountered. Thus the entire cost of loading was eliminated rather than thinking about making the file format different so lesser bytes are read in.


  1. Number of files loaded - strace and MOZ_TIMELINE (for files from jar)
  2. Any Directory enumeration : strace
  3. Any stat() happening : strace
  4. Dlls loaded : strace
  5. Are we eagarly building up any other resources: menus, hashtables
  6. Number of memory allocations : mallocsites
  7. datastructure or architectural improvements
  8. Number of objects created - BloatView


Here are some interesting stats on our startup:

  • Malloc: 22% (122,563 calls)
  • new: 15% (102,535 calls)
  • free: 3% (82,332 calls)
  • delete: 2.3% (70,722 calls)


Main tinderbox: Testerbox:

QA measuring startup and page-load

Daily results get posted to netscape.public.mozilla.performance newsgroup