Wednesday, October 31st, 2007

Gmail gets a JavaScript facelift

Category: Google, Showcase

Dan Pupius is a stellar JavaScript developer at Google, and he has been knees deep in producing a new front end framework for Gmail which is now launching into the wild, and it is all about speed:

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

4.3 rating from 48 votes


Comments feed TrackBack URI

That’s great, gmail is kind of laggy sometimes. I hope they spent some time lowering the login time as well because that’s the one that’s been bothering me the most.

Comment by Anonymous — October 31, 2007

Hehe…you guys are completely insane. Nice work. ;)

Comment by Jesse Kuhnert — October 31, 2007

This kind of programming reminds me of my Commodore 64 days. Every byte counts. Every clock cycle counts.

Comment by James MacFarlane — October 31, 2007

As far as speed improvements… I don’t know how much benefit I’m going to see. I have never, ever, found myself waiting for responses from gmail on anything but search for more than a tiny fraction of a second, and I’ve never felt anything resembling lag, except when I’m having network trouble besides.

I’ve been generally impressed by Gmail’s speed. The launch could be a bit quicker, but I really only launch every time it logs me out.

Comment by Trevor — October 31, 2007

Hmm. So a Google Engineer reverse-engineered jscript.dll. I am not so sure the DMCA covers this. And i doubt MS gave written agreement to Google.

Comment by lhe — October 31, 2007

Hmm. So a Google Engineer reverse-engineered jscript.dll. I am not so sure the DMCA covers this. And i doubt MS gave written agreement to Google.

Is it illegal under DMCA to reverse-engineer something for the purpose of learning how it works, while building something against its API rather than building something that implements some or all of its features?

Like, there’s a huge difference between (I think this is excepted in the DMCA but it’s just illustrative of my point) reverse-engineering a microprocessor to build a compatible microprocessor, on the one hand, and reverse-engineering a microprocessor to write a better-optimized compiler, on the other.

Comment by Trevor — October 31, 2007

Oh, and additionally, I doubt Microsoft would really mind Google making its products work better in IE, so MS doesn’t have to do the work themselves of making JS perform better. I bet they turn a blind eye.

Comment by Trevor — October 31, 2007

awesome post, thanks, Dion. This is the type of post I love — Engineers sharing their own insights into what they do, how they do it, etc. …I can’t wait for Gmail to be Gears-enabled as well.

Comment by Mark Holton — October 31, 2007

interesting article and a more in-depth follow up would be stellar. One thing i’d like to here more about is memory management. Gmail really eats up RAM, at least as far as firefox is concerned. I’ve never encountered a situation where I wished Gmail was “faster”, there have, however, been many times where I wished it was lighter (as far as memory usage, not JS payload).


Comment by brain — October 31, 2007

@brain:did you disable firebug? it eats all your memory when it tries to log all XHR requests

Comment by Uriel Katz — November 9, 2007

This is the way to go when you make a product… You must try to reach perfection.

@brain, you can always use the HTML UI or just use a POP3 client, it would be a lot faster.

Comment by Web Design NY — November 17, 2007

Leave a comment

You must be logged in to post a comment.