How long does it take to compile a web browser, Part 1

In today's brave new world, people can build and deploy a web app very quickly. However, on the other side of the equation, systems software such as web browsers are not getting any simpler. The cost of the rich media experience in modern web apps quite frequently borne by systems software including browsers, servers, and plugins. Just eyeballing, in Chrome (default multi-process mode), each tab take 30-100 MB of RAM. Luckily, I am not one to keep many tabs open concurrently, but many, many people do. A rich web experience can quickly gobble up whatever amount of memory you can throw at it. There are many people who have compared memory usage for Chrome, Firefox, Safari, and Internet Explorer (TechPP, CNet, Tom's Hardware, DotNetPerls, and many more I am sure), but, here, I would like to take a look at another facet of web browser complexity: source code size, time to build, and size of debug executable. This post follows and expands upon the type of study I did on open source finance software. These figures are a rough gauge of the complexity of each project. The motivation is this. The Chromium developer/contributor website cites a ~1.3 GB debug executable, 5000 build objects, 100 library objects, and > 4GB of virtual memory to build. This requires some serious metal to build. Curiously, Mozilla quotes far lower requirements (256MB/1 GB RAM minimum/recommended). When did web browsers become overwhelmingly complex artifacts by their own right. Why should the HFT community pay attention? Google and other browser makers have put tremendous engineering effort in optimizing the latency of the web. There may be a number of things we can learn to optimize financial systems, some of which speak web protocols. In the very least, we re-implement FIX and SWIFT in light of the engineering of the messaging components of browser systems. I will begin by giving an overview of the main components of three web browsers.

Web Browser	Source Code Checkout Size (MB)	K SLOC	Release Build (Real) Time (min)	User Time (min)
Firefox a66254dfa588 (pre 4.0)	457	3430	16.2	57.9
WebKit rev. 103339	4700	1848	52.72	143.23
Chrome rev. 115041	4900	2800	82.37	287.68

The SLOC breakdown is a little tricky. For Firefox, 3.7M of the SLOC are C/C++ files of which 3.34M are non-test-related code. 1.1M are JavaScript of which only 90k are non-test-related code. Safari (WebKit) has 1776kloc of C/C++/ObjC and 252kloc of JavaScript of which 72k of the latter are non-test-related. For Chrome, many of the dependencies had to be built. There may be an option to reuse a prebuilt version, but I wanted to measure the "out-of-the-box" experience. The WebKit and Chrome checkouts are a lot larger than that of Firefox because they include many auxiliary components. Chrome, in particular, includes a good chunk of WebKit since it is built on top of WebKit.

When I was building WebKit, the processor core utilization was a mixed bag. Sometimes I got great utilization with all cores at 100% but other times the build gets such on several bottleneck compilation units. Using the user versus real time as a rough approximation of utilization (there are a number of problems with this assumption but bear with me), compilation of Chrome had about a 3.5x speedup from an 4-core (plus hyperthreading) build, which amounts to a ~44% utilization of the virtual cores. For Firefox, the speedup was around 3.57x. For WebKit, speedup was was only 2.7x. Considering these experiments were run on a Mac Pro Quad-Core 2.8GHz, the core utilization is pretty good.