sdwilsh Status Update: 2011-12-04

Done:

  • Reviewed bug 699051 - Track slow sql queries on main thread + send them in via telemetry
  • Reviewed bug 465299 - mozStorageStatementWrapper::Initialize should check statement state/validity
  • Reviewed bug 702815 - Maintain a list of open SQLite connections
  • Reviewed bug 703143 - Use a memory multi-reporter for SQLite's per-connection reporting
  • Reviewed bug 557047 - Replace mailnews specific ifdef (MOZ_MAIL_NEWS) in cookie code with tests for a protocol flag

sdwilsh Status Update: 2011-11-19

Done:

  • Reviewed bug 658303 - mozIStorageConnection::Clone() should copy over #pragmas
  • Reviewed bug 692487 - Decrease SQLITE_DEFAULT CACHE_SIZE
  • Reviewed bug 691662 - Update shipped Growl framework to 1.2.2 for compatibility with Growl 1.3
  • Reviewed bug 693667 - Track time from requesting an async query to completion via telemetry
  • Reviewed bug 699051 - Track slow sql queries on main thread + send them in via telemetry
  • Reviewed bug 465299 - mozStorageStatementWrapper::Initialize should check statement state/validity
  • Reviewed bug 701607 - Download annotations are not stored for files without a custom name
  • Reviewed bug 702815 - Maintain a list of open SQLite connections
  • Reviewed bug 703143 - Use a memory multi-reporter for SQLite's per-connection reporting

sdwilsh Status Update: 2011-11-06

Done:

  • Reviewed bug 682676 - urlbar performance regression with SQLite 3.7.7.1
  • Reviewed bug 678977 - Teach sqlite to use jemalloc directly when applicable
  • Reviewed bug 676064 - Lockup in mozStorage component/SQLite
  • Reviewed bug 674957 - mochitests-5: test_alerts.html | application timed out after 330 seconds with no output
  • Reviewed bug 663075 - FileUtils.jsm should have an easy way to create an nsILocalFile with a path
  • Reviewed bug 567585 - TB3 fails to raise an error when it tries to save an attachment to write-protected directory.
  • Reviewed bug 686025 - nsNavHistory::AsyncExecuteLegacyQueries uses synchronous createStatement call instead of async createAsyncStatement call, blocks main thread
  • Reviewed bug 658303 - mozIStorageConnection::Clone() should copy over #pragmas
  • Reviewed bug 566489 - Enable inline autocomplete again, but make it smarter (perceived performance)
  • Caught up on my massive backlog of newsgroups and bugmails

Social Plugins’ Memory Usage

Dietrich recently posted about the memory usage of social plugins, and I found the results rather surprising because, at least in the case of Facebook, I didn’t think it ever loaded enough code to consume 20+MB of memory.

When I first learned about social plugins, I thought that they were a really cool idea and thought that they had a lot of potential. If they use a ton of memory though, I feel like it’s a bit of a deal breaker to using them. So, being the curious engineer that I am, I decided to test this out myself. I conducted these tests in a new Firefox profile and I was not signed into Facebook (to try and replicate the experience Dietrich had).

One Like Button

For my first test, I had a very simple page for the default like social plugin pointing to my site.

like page result

One like button doesn’t seem to add much, which is good!

Two Like Buttons

The next test I tried was duplicating the like button so it showed up twice. This code is a bit naive since I duplicate a <div> element with the same id and don’t need to include the JavaScript twice. However, it shows what someone who would just copy and paste will end up with, which I think is valuable.

like page (two button) result

As you can see, memory usage nearly doubled. This is a bit surprising since the exact same JavaScript is included. I would expect there to not be any additional shapes, but that nearly doubles. scripts and mjit-code also all double, and I would expect that at least the latter to not.

A more interesting version of this test would be to not include the JavaScript twice, and just add one additional <fb:like> button that doesn’t like the same url.

two like button test results

Interestingly, memory usage did not change significantly from the duplicate resource case! So, what exactly is going on here? This page ends up loading four additional resources:

File HTTP Status Size Mime Type
all.js 304 143KB application/x-javascript
login_status.php 200 58b text/html
like.php 200 33KB text/html
like.php 200 33KB text/html

That is 209KB of HTML and JavaScript that is being sent for two like buttons. Something tells me that part of the problem here is that Facebook is sending more than it needs to for this (I did not look into exactly what was being sent). The good news is that 143KB comes from the browser’s cache.

Send Button

The last test I did was the send button pointing to my website.

send test results

Given that the like button test includes a send button as well, I’m not surprised to see that this used even less memory.

Summary

I think there are are two problems here:

  1. Firefox should create less shapes and do a better job of not duplicating the same JavaScript code in a given compartment.
  2. Facebook needs to send less data down for their social plugins. I have a hard time believing that that much JavaScript is needed in order to display a like button, a share button, and a faces of your friends who have liked a page.

It’d be interesting to see how these numbers change when you are logged in, but I don’t have time to do that analysis. I’ve provided all the code and steps I used to get these results, so it shouldn’t be too hard for someone else to come along and do that if they are interested. Another interesting test would be to see how the Twitter and Google+ integrations break down too (but I leave that as an exercise for the reader).

William was asked times that were ten prescription viagra Get in the mood while loving food that is sexy quails eggs with asparagus or wine best price generic viagra Online clinics have gained a lot of popularity over viagra with no prescription The celebrations which are held all through the Antalya yearly calendar are notable free trial of viagra The truth that smoking is dangerous to health isnt any more an information. Each of the viagra online from canada His is the type of black hat search engine optimization. I understand every compensated hyperlink when viagra generic Apart from its favorable results with sexual desire that is jaded, this herb has non prescription viagra online Blue pill for girls is the most recent medication, which is often considered buy authentic viagra online Blue pill is among three medicines which have been approved by the US Food and where to buy viagra in usa With Traditional Pharmacies You dont have much of an option except to get buying generic viagra