monkeys on typewriters

So, both Austin and I were on vacation all of the last week. Just before we left, we realized that we had made the dangerous mistake of leaving Mason in charge around here. Despite all of our dire predictions, things didn’t seem to collapse around here. We may not be so lucky next time…

Anyway, now that we’re done vegetating, we’re ready to continue work on our next cool widget. And the one after that. (* Cue dramatic music. *)

Fair warning: This post will have extremely nerdy content. But you probably could’ve guessed that from the title.

Story time. On our latest widget, we have to display a significant amount of HTML that has been generated by JavaScript. By “significant amount”, I mean 275 plus lines of information that was generated and displayed by JavaScript. I know that 275 doesn’t sound like much when there’s a computer doing it, but it seemed to be slowing stuff down.

To display the information I was “printing” I would print it directly from a loop with the data. The solution I came up with was to try to buffer the information.

— Start technical description —

To display something on the screen is often much slower than generating the information you want to display. The process of buffering allows you to generate the content and print it to an intermediate “buffer”, then print it to a screen all at once. The idea is that it’s much faster to print more information once than it is to print small bits lots of times. Wikipedia has more information of buffers.

— More technical description —

When I say “printing” I’m kinda lying. JavaScript and HTML don’t exactly have the low-level console-type printing that C has (printf() anyone?). Ok. Lying again. There is write(), but it doesn’t really work well for any purposes beyond very simple printing. JavaScript uses a property called .innerHTML. Ok. Moving on.

— End technical description —

Now, I had always assumed that buffering wasn’t really necessary when printing HTML code to the document. I thought that the data that’s being printed is so small that there isn’t really any need. However this changes as you add loads of information.

This is what was happening in our new widget. I didn’t think that buffering would change much, but when you’re talking 10-second cold-starts something has to be done. So, what I decided to do was set up a very-imformal experiment to test the effectiveness of buffering in a situation such as this. Here’s our situation:

1. Printing out hundreds of lines of stuff through a loop.
2. These lines have links.
3. These lines also have dynamic content. I.e. content that is different for each iteration of the loop.

Based on these criteria, I created a test to see how well buffering works. I wrote a JavaScript function to run through printing 500 lines directly, and one to do it through buffering.

The results I got were pretty surprising. The un-buffered version took anywhere from 3 to 10 seconds to complete its task. The buffered version did it almost instantaneously.

Here’s the test files: the un-buffered version and the buffered one. Try it for yourself. (Disclaimer: only tested in WebKit. Gecko might do something completely different performance-wise.)

If you go to our page about the crew, clicking on the names of people will allow you to see each of their desks. The desks are probably the most accurate representation of what we’re like that’s on that page. Coale’s is particularly interesting.

We’ve decided that Coale’s “desk” shot is either a ping-pong table with Apple product placement or a MacBook with Kettler Sports product placement. Coale’s a big sports buff, so this made perfect sense But how did we get this shot? And why is the screen white?

This shot was taken with Photo Booth. From the MacBook being pictured. That’s why you can see the little green light next to the camera above the screen. We used a big mirror to cause the computer to take a picture of itself. Those legs you see at the top of the image are Coale’s. I think I was the one who was holding the mirror.

I know this little anecdote probably bored you to death, but it’s over now, so you can wake up and be on your way.

Yes, we are still working on this new widget that we’ve been teasering (cool, I invented a new word!). Here’s yet another teaser. This is a blurry image of the widget’s interface. If you care, it’s a motion blur created by Core Image Fun House. That’s a really fun app. You should try it if you haven’t. Oh right. The pic.

Keep in mind that I may have stretched, distorted, or recolored this image before applying the blur. Just a thought.

Wow. A recent post on Microsoft’s Mac Mojo blog (The Mac BU’s Blog) stated an amazing/stunning/horrifying fact. Ever wonder how many lines of code are in Microsoft’s Mac Office?

30,000,000.

Thirty million.

Here’s what else they had to say about it:

Just to throw another mind-numbing number out at you, there are about 40 lines of text on the page of an average paperback book. That means one developer is responsible for about a 10,700-page book. Or if you break it down smaller, if the average paperback is 300 pages, that means each developer is responsible for about 35 or more paperbacks on his desk. Imagine trying to find a single typo in all those books — that’s what most bugs are, don’t ya know!

No wonder it’s taking so long to get out the Universal Binary of Mac Office.