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.
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
shapes, but that nearly doubles.
mjit-code also all double, and I would expect that at least the latter to not.
<fb:like> button that doesn’t like the same url.
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:
The last test I did was the send button pointing to my website.
Given that the like button test includes a send button as well, I’m not surprised to see that this used even less memory.
I think there are are two problems here:
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).
I’m going to write something that will probably surprise you. I say this because it sure surprised me when I realized I was even considering what I’m doing a possibility. I’m going to be moving on to something a bit different in the mobile space, and it’s going to be a different kind of challenge for me.
June 1st will be my last day at Mozilla. I’ve learned so much over the years working there, and choosing to leave was the hardest decision I’ve had to make. I do not intend to disappear from the project, however, but my activity level will decrease. Feel free to continue to send review requests my way and cc me to bugs you want my opinion on, and I’ll do my best to reply in a timely manner.
So long, and thanks for all the fish.
I handle a lot of code review and code feedback requests these days. However, it’d be great to get more people doing this for a number of reasons:
- More people exposed to more parts of the code base
- More review bandwidth so more work can be checked into the tree
- Less dependence on a small set of people
In order to get more people doing this, it would be good to document to look for, and how to make sure the code is sound. I’m sure every reviewer does things a bit differently, but I’m going to share my process. There are two types of review I do these days: feedback and review.
Feedback is pretty simple to do, and I can usually fly though any patch (even large ones) quickly. This isn’t very thorough (in fact, I tend to keep it to general comments), but I look for the following things:
- correct API usage (XPCOM, jsm, whatever)
- internal invariants are not violated
- any new APIs created make sense and aren’t confusing
- code style matches what’s there, or follows the style guide
Review is more important because once a patch gets r+, it can generally land in the tree. Consequentially, I tend to spend a lot more time on any given patch. In addition to all the things I do for a feedback request (which are looked at more closely for a review), I’ll also look at the following:
- evaluate how well tested is the code that is being added/modified. If it isn’t well tested, I’ll generally suggest a set of test cases that I feel are the bare minimum this needs to land.
- evaluate how this might impact other work going on in this area of the codebase
- ensure this doesn’t add any I/O on the GUI thread
- apply the patch and run the tests
- if the patch looks like it might regress performance, ask for the author to verify that it does not
Note that a number of these things may not be done if I know what the patch author has already done to ensure the patch is safe.