We have also been fanatical about speed. Even on a fast Internet connection, it can take a second to request and render a new web page, and when you read a lot of mail, these seconds can accumulate to hours waiting for email to load. We’ve spent a lot of time profiling all parts of the application, shaving milliseconds off wherever we can, and figuring out workarounds for some pretty deep-rooted issues with the current browser implementations. Some of the most common actions should be faster now. For instance, we prefetch messages in the current view, so when you open an email your browser doesn’t have to talk to Google’s server; it just displays the message. These techniques really shine on newer browsers and computers. Using an alpha version of Safari 3 on a MacBook, we’re seeing sub-200ms times when opening messagesâ€”pretty quick.
Aaron Boodman of Greasemonkey and Gears fame also weighed in:
At Google, we dogfood all our products. That means, among other things, that we use Gmail all day for all our internal mail. I don’t know of any other company producing web mail that can claim that. It also means that we have really high standards for these products. 500ms latency is usually considered great for a web application, but for something you use all day, it just won’t cut it. Because of this, the Gmail team has been to hell and back several times over the course of this project, trying to shave milliseconds off frequent operations.
As one small example, one team member reverse-engineered jscript.dll to figure out how its GC algorithm worked, and was horrified to find that it had hard-coded, arbitrary limits on how many objects could be allocated before a GC would occur. This led to an insane amount of effort optimizing the code to reduce the number of allocations in core code paths.
I will try to pin Dan down on some of the practical details on how you can make your apps run fast too. It is great to see a new rev of one of the early Ajax pioneers.
Posted by Dion Almaer at 1:05 am