Wednesday, December 24th, 2008

Giving developers and users responsiveness data

Category: Browsers, Performance

I posted on my personal blog about using the crowd to tell us about browser responsiveness in which I discussed giving developers information about browser responsiveness and how add-ons can affect it:

I have had some folks talk to me about responsiveness issues with Firefox 3. I have had a fantastic experience, and currently I run Mozilla nightlies / Minefield / Shiretoka (3.1.*) and WebKit nightlies side by side. I am very happy with the shape that Minefield is in.

Of course, the issue with the extension mechanism with Firefox is that you get a window to the entire world (which has also been a reason that lead to amazing add-ons). Since this is the case a bad add-on can do a lot.

Chrome does a good job showing you basic info about a tab (memory etc). What if we did that and more for add-ons. Give me top for the browser.

Now, this is a lot of engineering away, so can we use the crowd to help out?

What if we created an add-on that would track responsiveness information and send it back (anonymously) to the cloud (say, to Weave). We could use math to work out probable culprits and could even ship that information back to the people using the add-on. Thus, you would then find out that FooAddOn seems to be a culprit that slows down the browser. Maybe it could be called Vacinate-addon.

Then I got talking with Dav Glass who is working on a very interesting proof of concept BrowserPlus Profiler:

A service that analyzes the memory and cpu usage of a web browser. The service can take 1 sample or multiple samples at a specified interval. When sampling at intervals, at most 1,000 samples are taken. If you provide a callback function, your javascript will be called after every sample is taken. If no callback is provided, all samples are stored in an array and returned after start() completes or stop() is called.

The sample object is a map with the following keys (most values are floats):

  • [sample] – the sample number (1-1,000)
  • [time] – the string representation of the time the sample was taken
  • [sys] – the percentage CPU “sys” processes are using
  • [user] – the percentage CPU “user” processes are using
  • [ffxcpu] – the percentage CPU Firefox is using, or -1.0 if it is not running
  • [ffxmem] – the amout of memory Firefox is using, or -1.0 if it is not running
  • [safcpu] – the percentage CPU Safari is using, or -1.0 if it is not running
  • [safmem] – the amout of memory Safari is using, or -1.0 if it is not running

This is very early stage, and they are looking for good people and ideas on how t get good data across platforms (browsers and operating systems). I would love to see this.

Posted by Dion Almaer at 7:09 am
1 Comment

4 rating from 6 votes

1 Comment »

Comments feed TrackBack URI

I can easily imagine (and believe) that the Chromium bods already have in mind a threaded channel for addons. I’m not 100% up-to-speed with its development (I’m awaiting a proper Linux build), but there’s no chance at all that they’ve ignored addons, they’re probably beavering away porting or cloning the best Firefox ones so they can hit the ground running. That said, BrowserPlus Profiler does look like a most useful tool!

Comment by oopstudios — December 27, 2008

Leave a comment

You must be logged in to post a comment.