theme selector

light blue screenshot grey screenshot navy screenshot dark green screenshot red and black screenshot
 

by Tony Chang
tony@ponderer.org

All opinions on this site are my own and do not represent those of my employer.

Creative Commons Attribution License

Firefox development

May 23, 2006, 02:26am EDT

 

 

It’s been a long time since I posted to this blog. I’ve been busy working on landing a new feature in Firefox. I wasn’t responsible for the original code, but I’ve been porting it to the Firefox code base.

It’s been an educational experience as I learn about working with the Mozilla code base. The two key things I’ve learned are to think about memory leaks and performance metrics from the beginning.

Memory Leaks

In theory, this shouldn’t be an issue since javascript has garbage collection, but in reality it’s very easy to create a cycle and leak memory. [1] From now on, I’m developing all javascript (web sites, extensions, and core) using a debug build of firefox with XPCOM_MEM_LEAK_LOG set. Dealing with memory leaks incrementally is easier than trying to track them down after you’ve written thousands of lines of javascript. It also makes you think about how to design for the destruction of a JS object early on. Having a single shutdown hook is cleaner than having multiple unload event listeners and xpcom-shutdown observers.

Ts and Tp

Browser startup time (Ts) and page load time (Tp) are closely monitored on a tinderbox. Like memory leaks, it’s easier to incrementally deal with these by changing your design than trying to deal with a 20% regression after you’ve implemented the feature. This is one of the mistakes we made with Google Toolbar on Firefox and something that we’ll be actively working on speeding up in the next few months.

Anyway, maybe in the future I’ll post on XPCOM interfaces, JS wrappers, and script friendliness.

[1] I would argue that it’s easier to deal with C++ memory leaks than javascript memory leaks because it’s a well understood problem at this point and we have tools and abstractions (smart pointers) for dealing with them. Javascript memory leaks are more magical and aren’t as obvious from just inspecting code.