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.