Friday, June 7, 2013

Tech Tuesday: Our Technology Stack

June 4th, 2013 by Alan
About a year and a half ago we moved from dedicated servers over to AWS. Since then, a lot has changed in how we think about servers and what goes on behind the scenes. This Tech Tuesday is dedicated to revealing the magic behind how the site operates in the cloud.
Clusters and Instances:
Thanks to AWS, we no longer have to think on a server level. Instead, we think of everything as a cluster of instances, and an instance is essentially a virtual server where we don’t have to worry about the hardware. We never have less than two instances per cluster (in case one goes down), and some clusters can have as many as 50 during peak times. Each instance in a cluster is the same as the rest in the cluster, and every cluster is spanned across at least two availability zones in case one has an outage. We’re also able to shutdown any instance at any time (even randomly if we feel like it) because when an instance goes down another takes its place within a few minutes.
It’s a relief to not have to worry about the hardware behind the instances. If one instance becomes unresponsive, then it’s automatically terminated and a new one is spawned. As long as the instances aren’t regularly becoming unresponsive, we generally don’t care what happened to it because by the time we even notice, the new instance has already taken over. There’s no impact to the end users because the load balancers are smart enough to automatically route traffic away from problematic instances before they’re even terminated.
Every cluster has AWS AutoScaling configured for it. This lets us start up more instances automatically if we have spikes in traffic. Additionally, if we have too many instances and not enough traffic, then automatically shut some down to save a few dollars on our AWS bill. Autoscaling is arguably the best feature AWS has to offer, and if you’re not using it than you better have a good reason as to why not.
The clusters we have are: WWW, API, Upload, HAProxy, HBase, MySQL, Memcached, Redis, and ElasticSearch, for an average total of 80 instances. Each cluster handles the job that its name describes, all working together for the common goal of giving you your daily (hourly?) dose of image entertainment.
A walk through the typical Imgur request:
Every request for Imgur first has to go through the HAProxy cluster. The first thing that happens when it reaches this cluster is Nginx checks if it already has a cached version of the response available. Every single page on Imgur is cached for 5 seconds, a technique commonly called microcaching. If you’re not signed into Imgur and you’re accessing a popular page, then chances are this is where your request will end. If no cached version of the page is available, then the request goes to HAProxy which decides which cluster will handle the rest of it. If you’re accessing imgur.com then you’ll go to the WWW cluster, api.imgur.com will go to the API cluster, and if you’re uploading or editing an image, you’ll go to the Upload cluster.
When you hit the WWW cluster you’ll be round-robin’d to an instance which will handle the request. This cluster is hooked up to the Memcached, Redis, MySQL, HBase, and ElasticSearch clusters. Since the site is coded in PHP, you’ll first reach Nginx which will send you off to php-fpm. Unless all the data for the page is cached in Memcached (highly likely), then you’ll probably be getting the data from the MySQL cluster. If your request is for a gallery search, then you’ll get the data from the ElasticSearch cluster, and some specific data is also stored in Redis and HBase. By this time, the request should have has everything it needs to form the page. It pieces it all together, travels back out to the HAProxy cluster, is microcached by Nginx, and your browser renders the page. All of this happens in mere milliseconds.
Requests to serve direct images are much different. The first thing you should do when your website starts receiving lots of traffic is leverage a Content Delivery Network (CDN). The point of a CDN is to offload all requests to static files, such as images, css, and js files, to a faster network. CDNs are optimized to serve static content as fast as possible and will be much faster than anything you can hope to achieve with your own servers. All requests to images go to our CDN, which will check if a cached version of that image already exists on their servers. If it does, then the request never hits our infrastructure at all and the CDN displays the image. If no cached version of the image exists for them, for example if the image was just uploaded and is brand new, then the CDN grabs the image from Imgur and displays it. At this point, every subsequent request for that image will be cached on the CDN and Imgur is no longer responsible to displaying it.
Below is a diagram of how they all work together:



That’s about it for this Tech Tuesday. Questions are welcomed in the comments!
Alan Schaaf
Founder & CEO

Posted in Tech Tuesday | 48 Comments »

Recreate the Awkwardness Contest!

June 3rd, 2013 by Sarah

Imgur and Awkward Family Photos are proud to present the Recreate the Awkwardness Contest. Follow the lead of Danny McBride and Maya Rudolph above and recreate one of these awkward family photos: http://imgur.com/a/OOFji. Stay true to the originals or add your own touch of cringe-worthiness.
The winner receives a Nikon D3100 14.2MP Digital SLR Camera plus a lifetime pro account, and more prizes from Imgur and Awkward Family Photos!
Check back on June 10 for instructions on how to submit your awkward photo recreation.
Posted in Contests | 2 Comments »

Our Favorite Images from May 2013

June 1st, 2013 by Sarah
Welcome, summer! We’re glad you’re here, but first we have to pay homage to the month that came before. There were so many phenomenal images this month that it took days to narrow down to these ten gems. We hope you’re more excited about them than Armind was about his National Spelling Bee win.
Eyebrows & Mustache
Favorite comment by MyBrotherIsLuigi: Ladies, this is what happens when you leave your child alone with their father.


My typical day at work.
Favorite comment by MetaphoricalFox: The right amount of mayhem.


Google Streetview captures the glorious moment when my buddy kicks his now ex-gf out of his house
Favorite comment by Idonteatenoughfruit: Revenge is a dish best served at the side of a road.


What I saw when I finished mowing the lawn yesterday
Favorite comment by MichaelMendez: sir i believe your dog is spoiling.


Comedian Kurt Braunohler hired a sky writer to do this over LA
Favorite comment by FalseOasis: I NEED MORE FUE


Khaleesi
Favorite comment by ImTheSwanQueen: “Touch my beard, and we will burn you first!”


Summer is Coming
Favorite comment by RobbStarkKingOfTheNorth: What do we say about sunscreen? Not today.


6th grader advice to next years 6th grader; surprisingly deep.
Favorite comment by Caniewak: Rivaled only by “Be excellent to each other.”


The ritual is COMPLETE
Favorite comment by TheyStoleMyPrecious: He’s trying to summon Cathulu


So close
Favorite comment by creatingusernamesgivesmeanxiety: My dog waited at the door for 10 minutes to come in…all while the door was open. http://imgur.com/upN8XbT


Posted in Featured Images | 19 Comments »

Tech Tuesday Takeover: Self-Serve Ads

May 28th, 2013 by Sarah
Oh no! The Imgur sales guys have hijacked Tech Tuesday! Today we are going to talk a little about how we handle our advertising business. Don’t panic, this post will cover some new ad technology that we are implementing today in the hope of improving the overall role that ads have on our site.
As many of you know, we are an independent bootstrapped company. Since we offer a free service, understandably, people always want to know how we keep the lights on, pay our ginormous hosting bills and still manage to keep the Imguraffe well fed.
We are able to support the company with revenue generated from ad sales, Pro accounts, commercial hosting and schwag from the store. A sincere thanks to all of you that support us through these paid products or decide to not use Adblock while browsing Imgur!
On the ad sales side, we work with large branded advertisers as well as ad networks. Ad networks are third-party companies that work with thousands of websites and hundreds of advertisers. They act as the middleman, bringing Imgur ad campaigns from advertisers we don’t work with directly. Although we have very strict guidelines for the types of ads we accept (only two formats, no auto-sound ads, no auto-expanding ads, no pop-overs or unders), we can’t always identify every campaign that’s running. Even with a ton of screening mechanisms in place, sometimes bad ads sneak through. Please know we hate these ads, too! We use every report we get through support@imgur.com to track down the offending networks and campaigns and squash them as soon as we can.
Ads play an important role in supporting the site, but we would prefer that they add value, or at least not detract from your experience. As part of our ongoing effort to maintain better control of our ads and to improve our ad quality, we are looking to develop direct relationships with our advertisers. To forward that goal we are excited to announce a new self-serve ad platform. This new system will allow you (or your company) to easily setup an ad campaign that will be displayed to your fellow Imgurians.
How does it work? Easy.
1. Visit our self-service page
2. Choose to target US only or the entire world
3. Select your budget
4. Upload your ad (or you can create one on the platform)
5. Enter payment details and submit

After a quick review to ensure that the creative looks good and your landing page is working, we will set the campaign live, typically the same day.
Aside from knowing that our community is full of awesome, funny, good-natured folks that love cat GIFs, we have also provided a few quick stats about our audience. If you are interested in targeting a specific geography (city or country) or if have any other questions about display ads or sponsored image ads please email us at sales@imgur.com.
75M+ unique visitors (almost 50M from US)
340M total visits per month
4.1B page views per month
70% Male
Over 50% Ages 18-34
Matt
Chief Operating Officer, Imgur

Posted in Features, News, Tech Tuesday | 12 Comments »

Tech Tuesday: jQuery DOM performance

May 21st, 2013 by Sarah
jQuery is called the “write less, do more” JavaScript framework. Invented by a fellow alumnus of RIT John Resig in 2006, it has changed the face of JavaScript development forever. Here at Imgur we use a lot of jQuery because it really does accomplish its aims and makes a lot of things pretty simple. The simplicity comes at a cost, however. jQuery is not nearly as fast as native DOM. Because it is a library sitting on top of the native DOM, it can never be as fast, and in certain contexts the performance penalty can become quite burdensome. We’ll examine one such context here.
If you’ve ever loaded a page on Imgur with a lot of comments, you’ll notice that it’s quite slow right now. We’re working to fix that, and part of that solution is sending comment data to the web browser to build the tree of comments rather than building it on our servers and sending out the result to you. By doing that, we off load a lot of the processing power to the web browser and also can utilize caching to make it even faster. Some pages can have a lot of comments to lay out – thousands in some cases, and each comment contains at least 19 elements, so we could be laying out around ~19,000 elements. Whether we do that in jQuery or native DOM is a choice: is the benefit of jQuery (“write less”) worth the performance penalty? Let’s examine the performance penalty to decide.
I wrote a small library called ThinDOM that sits on top of the native DOM methods and lets you do fancy chaining like jQuery. I’ve written a test suite to examine the performance characteristics of jQuery vs. using innerHTML vs. ThinDOM, and through the wonder of technology you too can replicate my results! Science!




The test page simulates very closely the actual process involved in building each caption. The results, though not expected, are a bit shocking in the differential.



Happily jQuery is getting better over time, but its performance is still lacking. The InnerHTML method, though fast, is not quite as fast as using the native DOM methods, and the difference is statistically significant (p < 2.2 E-16). ThinDOM is about twelve times faster than jQuery 2.0 edge. jQuery, like all abstractions, leaks. The promise of jQuery is that you don’t need to know about DOM, you just need to know about HTML and JavaScript, but it leaks because, if I know a bit about DOM, I can write a library that is an order of magnitude faster, and, if I don’t know about DOM, then my code is going to be awfully slow. Knowing when to use jQuery is knowing when you aren’t going to be blindsided by these performance issues, or when the performance penalty is less than the cost in developer time – time spent writing the code.
On a site like Imgur with sometimes hundreds of thousands of people hitting images with hundreds of comments, even a small performance gain can be “worth it” since developer time is averaged out over every user. As we implement this feature over the next few weeks we hope this should make captions feel much more responsive, especially on more popular images.
I ran all tests on a machine with a Core i5 760, 16 GB of RAM, on Windows 7 SP1 on Google Chrome 26.0.1410.64 m.
Jake
Front End Engineer, Imgur

Posted in Tech Tuesday | 32 Comments »

Alan takes over the Imgur Twitter!

May 20th, 2013 by Sarah
Join Alan Schaaf, Founder of Imgur, this Wednesday (5/22) at 4PM PST for an ask me anything–Twitter style! Alan will be taking over the official Imgur twitter (@Imgur) to answer your questions about Imgur, bombard you with cat GIFs, give you relationship advice, or tell you about his favorite images. The choice is yours.
Follow the conversation by using #AskImgur.


Now, here’s a cute sloth:

Posted in News | Comments Off

Tech Tuesday: Conception of an Icon

May 14th, 2013 by Sarah
In the official Imgur logo, the ‘i’ is the most recognizable feature. When stripped down even further, the ‘i’ is memorable not for the font or its positioning in the word, but for the green dot. You may have noticed that with the launch of our official app (currently in Beta), we have also introduced a new addition to our brand. I am lovingly referring to it as “The Dot”.

In creating the app icon, we took to the gallery for inspiration. Aside from the favicon (browser icon) and various merchandise that uses the ‘i’, the community has embraced the ‘i’ in their own Imgur-themed original content:



These posts don’t all use the same font or style, but they all make the dot on the ‘i’ green! This exciting revelation also opened our eyes to how much the green dot is used for design elements on the site:






Thus, we designed another brand icon that stands out from the crowd. In comparing the Dot to other app icons, it really pops!

In short, the dot has always been there, but now has been introduced to the ranks of the Imguraffe and the trademarked ‘i’.

The making of the Dot

In the best interest of Tech Tuesday, I’ll take you through how I created the icon! To start, I found a really simplistic tutorial online for making a sphere type shape utilizing photoshop (http://www.youtube.com/watch?v=CeSjmxNfqxg). This album will quickly highlight the steps for this as well:
Imgurians, what do you think of the Dot?
**The official Android app (BETA) is now available in Google Play in Australia, Canada, and the UK.
**Apple continues to reject our iPhone app because of images of PedoBear, but we’re hoping to be approved soon.
Tony
Head of User Experience, Imgur

Posted in News, Tech Tuesday | 110 Comments »

Tech Tuesday: Backbone and I

May 7th, 2013 by Sarah
In the development of our mobile application, we decided to use PhoneGap so we could easily distribute the application to as many platforms as possible. When we were first designing the application, we knew we would need a robust JavaScript framework to give us a solid code structure, but we needed something very light weight inside of a mobile space. With all of that in mind, we decided on BackboneJS. It gives you a solid start on building a JavaScript site with a great code structure. The structure comes from its four major classes: Models, Views, Collections, and a Router. Each of them help keep data where it should be, allowing you to focus on interactions and building the best experience.
So, what do each of these classes do? Let’s talk.

Models

A model is where you store data about a specific item, one of our most commonly used Models is a Comment. This model will contain data about a comment, id, the id of the gallery item it’s attached to, and the comment text itself. What is so great about Backbone Models are that we just have to point them to the API endpoint, and it will automatically sync the data for us. Since both Backbone and the Imgur API follow REST standards, they can easily communicate with each other, and you don’t have to spend time tweaking things to make them work together. Here’s an example of how you can create a comment with the Imgur API and a BackboneJS model:
var Comment = Backbone.Model.extend({
  'urlRoot' : 'https://api.imgur.com/3/comment'
});

var myComment = new Comment();
myComment.save({
  'image_id' : 'j17loBb',
  'comment'  : 'Ace Ventura rules!'
});
By calling .save() we not only create an object with the given data to manipulate in JavaScript, but also send a POST request to the Imgur API to create it in the Database. That allows us to worry about other things, rather than when to save the data to the API. In a similar vein, you can call myComment.destroy() and it not only deletes the JavaScript object, but also deletes it from the server and triggers a destroy event. There are a number of methods and events that allow models to communicate with an API behind the scenes so you can worry about other things.

Views

Backbone views is probably where we save the most code, simply because we are reusing the data every chance we can. When you hit a gallery view in the app then click an image, we don’t actually fetch any data for that image. We already have the data from our first request, so we simply show you a different view of the image. By doing this we can keep everything, sync across the app and greatly reduce the number of requests we need to make to the server. Here’s a quick example of how you might render an Image:
//First create the View Class
var ImageView = Backbone.View.extend({
  class    : 'image',
  initialize : function() {
    this.listenTo(this.model, 'destroy', this.remove);
  },
  template : _.template(
      '<h1 class="title">' +
        '<%= _.escape(title) %>
      '</h1>' +
      '<img src="http://i.imgur.com/<%= id %>.jpg />'),
  render : function() {
    var attributes = this.model.toJSON();
    this.$el.html(this.template(attributes));
    return this;
  }
});
Now we can use the view with a Backbone Model. For the sake of simplicity, let’s say we have an Image Model, myImage, with all the data we need.
var imageView = new ImageView({
  'model' : myImage
});

//this is simply taking the html rendered in 
//the image view, and using jQuery to insert into the DOM for us
$("#comments").html(imageView.render().el);
The output for imageView.render().el is going to look something like this:
<div class="image">
  <h1 class="title">
    Went running yesterday for the first time in a long time. 
  </h1>
  <img src="http://i.imgur.com/j17loBb.jpg" />
</div>
We are also using the _.template method in the example since it comes with Backbone, but you can use any JavaScript templating system that you want. By using a template, we can say that we want all of the objects rendered with this view to look the same. We also have some protection against people trying to inject html into our website by calling _.escape to the title, which is user input.
Now a user wants to delete that image, normally you’d have to setup code to make a delete request to the server, delete the object, and remove it from the HTML as well. However with BackboneJS, we can simplify that to : 
myImage.destroy();
In the initialize function in the ImageView, we have a call to this.listenTo. This adds an event listener for the model on the ‘destroy’ event, and will call the remove function associated with the view. There is a default remove function in all BackboneJS views that removes them from the DOM, and all of the handlers associated with them. As we mentioned earlier, the destroy function also makes a DELETE request to the URL in the model. By simply destroying the model, we have removed it from the screen, memory, and the database. Pretty sweet, right?

Collections

A collection is, at its simplest, an array of models. The great thing about collections is we can simply hook it up to a URL like we did with models before, so you can just say “fetch” this data, and you’ll get all of the data your heart desires. Let’s take a look at how the Imgur Gallery works:
var gallery = new Backbone.Collection([], {
  'url' : 'https://api.imgur.com/3/gallery'
});

gallery.fetch();
Now we have a Collection of models, with all the image data for the front page of Imgur. What can we do with all of this new found data? Well, we have already defined a view for images, ImageView. Now, let’s use that to render all of the images in the gallery.
First of all, we need to create a collection view. This is the same as a normal view, but you’ll be passing a collection to it. The render function will know how to deal with an array rather than single model.
var GalleryView = Backbone.View.extend({
  class  : 'images',
  render : function () {
    //we don't want any old stuff there if we render this multiple times.
    this.$el.empty();

    //loop through each model, and render them separately
    this.collection.forEach(this.renderOne, this);
    return this;
  },
  renderOne : function(image) {
    var view = new ImageView({
      'model' : image
    });

    this.$el.append(view.render().el);
  }
});
Now that we have the collection view defined, and we have the collection data, we can render it to the screen.
var galleryView = new GalleryView({
  'collection' : gallery
});

$('body').html(galleryView.render().el);
So the output of the HTML body will be:
<body>
  <div class="images">
    <div class="image">
      <h1 class="title">
        Nobody reads anything on twitter, and Ricky Gervais proved it
      </h1>
      <img src="http://i.imgur.com/mouHhUz.jpg" />
    </div>
    <div class="image">
      <h1 class="title">
        Went running yesterday for the first time in a long time.
      </h1>
      <img src="http://i.imgur.com/j17loBb.jpg" />
    </div>
  </div>
</body>

Router

The last of the major Classes of Backbone is the Router class. This class is where we define when we want to use the views and collection data. It’s basically the glue that brings everything together. The routes are url paths that you intercept and want to display. Basically, they use regular expressions to make everything in your life easier. Let’s take a look at how we might render a gallery then move on to a single image with the classes we used before.
var ImgurRouter = Backbone.Router.extend({
  routes : {
    '/:id' : 'showImage',
    ''   : 'showGallery'
  },
  initialize : function() {
    this.gallery = new Backbone.Collection([], {
      'url' : 'https://api.imgur.com/3/gallery'
    });

    this.gallery.fetch();
  },
  showImage : function(id) {
    //find the image in the gallery, saves ajax requests!
    var image = this.gallery.get(id);    

    if(image) {
      var imageView = new ImageView({
        'model' : image
      });

      $('body').html(imageView.render().el);
    } else {
      //show a fancy 404 page with a giraffe.
    }
  },
  showGallery : function() {
    var galleryView = new GalleryView({
      'collection' : this.galleryCollection
    });

    $('body').html(galleryView.render().el);
  }
});

var router = new ImgurRouter();
Backbone.history.start();
Let’s say your website is http://imgur.com. When you visit that link it will go to the showGallery function, render the gallery collection, and insert it into the body tag on the page. If you go to http://imgur.com/j17loBb it will call showImage, and take you to a page where it shows that image. We also did a really quick improvement to reduce the number of ajax requests in the router. We are simply selecting all of the images in the gallery on load, then using that data to navigate through the application. It’s important to note that if the ajax request isn’t finished by the time you try to load the pages, you’ll see nothing. To fix that, we can add some wait times and do all sorts of checks in the router, or we can simply modify the view. If we add the ‘add’ event handler to the gallery view, we can render them as data comes back from the server.
The biggest advantages to using backbone are code clarity, organization, simplicity, and reduction of AJAX requests. The way Backbone breaks down code into chunks allows us to easily organize the codebase. Also, by maintaining data in collections and models we can keep track of them to re-render later and in different ways depending on the view.
While these are some watered down examples of how you might use BackboneJS to build your own application with the Imgur API, I hope it helps you start off with some awesome apps. There is a lot more information on BackboneJS at http://backbonejs.org, http://backbonetutorials.com, and http://codeschool.com. Hope to see some awesome apps built with the Imgur API and BackboneJS! Brace yourself; the Imgur Mobile Application is coming.
Josh
Front End Engineer

Posted in Tech Tuesday | 15 Comments »

Our Favorites Images from April 2013

May 1st, 2013 by Sarah
It’s been a crazy month. Once again, the Internet delivered a variety of clever and entertaining April Fool’s pranks (thanks for sending us your Snail Mail uploads). Online image sharing played an important part in speedy suspect identification at the Boston Marathon tragedy, images from which shocked, saddened and inspired people all over the world. Meanwhile on Imgur, user identities were revealed in a flood of lovely selfies, and, if you missed the Moon Moon joke, two days worth of front page material went over your head. Despite it all, we’ve seen another batch of phenomenal images. Below you’ll find our favorite ten. Enjoy!
Nailed it.
Favorite comment by TheFeralCat: Thrift Thor.


The trouble with perspective.
Favorite comment by McTrick: Butterflies in the sky, I can stand twice as high. Take a look on top of books.


My doctor said: “You kinda look like that guy on the wall over there!”…
Favorite comment by chemistrydoc: Oh my G.E.R.D.


My wife and I are expecting our first child…and apparently a cat too.
Favorite comment by FreckleCharms: If I fits…


Whoever did this just won at life
Favorite comment by napsmear: http://imgur.com/yRUsk8C


Nothing in this picture is not Snoop Dogg
Favorite comment by anniexkimchi: Awyeah. It’s a sunizzle, and treeizzle, with leavizzles on its trunkizzle, and I love the grassizzle, and the beautiful skyizzle.


Boston looks like a ghost town right now. (Click image for full album)
Favorite comment by Killingjezus: So when everyone should stay inside, redditors go outside?


If you faceswap Justin Bieber and Taylor Swift, they look like a cute lesbian couple
Favorite comment by Zalophus: Turns out not face swapping still has the same effect.


oh…..OH I look so FABULOUS.
Favorite comment by merpderps: waaaahhhhhhhhhhhhhow you doin?


Perfect Timing!
Favorite comment by stevengracie: I’m not even joking this time somebody put 5 onions in my lemonaid


Posted in Featured Images | 20 Comments »

Tech Tuesday: Avoiding a memory leak situation in JS

April 30th, 2013 by Sarah
Javascript stands at the forefront of Imgur’s core technologies, whether running on the main site itself or as part of the mobile app. For the latter, we decided to use it heavily with PhoneGap as the platform on which to build the Imgur mobile experience. As performance on mobile devices is much more restrictive, we have to be confident that memory usage is kept minimal.
If you build it, will they come? Probably. But they won’t come back if there are blatant memory issues within the app. The task of cleaning up memory seems daunting with so much happening behind modern JS engines. Where do you start looking?

Dangling References

In lower level programming languages, you explicitly allocate memory whenever you use variables during runtime. Then you use the space you’ve allocated for whatever you want and, when you’re done, you de-allocate that memory so it can be reused later to hold other things.
Luckily in JS, we have a very “magic” simple way of doing that, which is to declare that a variable and let the garbage collector (GC) worry about which variables we are ‘done with’. Once the logic gets complicated and there are more things going on (e.g. loading images, fetching comments, rendering views) the amount of memory space there is to work with for each task shrinks dramatically. If the GC cannot resolve whether something is no longer needed, it does not free the memory, causing a memory leak.

An example


  <html>
      <script>
      function leak() {
        // 1. Ref to the <button/> in current scope.
        var el = document.getElementsByTagName('button')[0];

        // 2. Make an 'onclick' property in the element that "subtly" refs el.
        el.onclick = function() { 
          // el is defined in here due to the closure created in leak()
          alert('hello world!');
        };

        // 3. Take up a fair chunk of memory within this closure by 
        el.leaky = 'awfulness'.split('').join('awfulness')
                              .split('').join('awfulness')
                              .split('').join('awfulness');
      }
    </script>
    <body onload="leak()">
      <button>foo</button>
    </body>
  </html>
The GC works to free memory if the proper references to an object are broken. In this instance, when we call leak(), it creates a closure that contains the variable el, which is a reference to the <button/>. If all we want to do is alert ‘hello world!’, then we probably don’t notice the closure within the scope of the onclick function. But that doesn’t mean it’s not there. So it’s actually possible to use el within the onclick function due to this.
Logically, we would never use el again in that context, though the GC can’t be absolutely certain of that. Hence it never cleans up el after leak() has been run.

To fix this, we have to explicitly break the reference that el holds by setting it to something like undefined or null. An alternate solution could be avoiding the closure altogether.

    ...

        // 3. Take up a fair chunk of memory within this closure by 
        el.leaky = 'awfulness'.split('').join('awfulness')
                              .split('').join('awfulness')
                              .split('').join('awfulness');
        el = undefined;
      }
    ...
This one case of memory management merely scratches the surface of the optimizations we are constantly on the look out for as we try to improve your journey across the GIF filled expanses on this side of the Internet.
Jim
JS Engineer

Posted in Tech Tuesday | 13 Comments »
« Older Entries
store blog help site stats apps request d
Posted by at

1 comment:

  1. UtahOctober 11, 2016 at 11:21 PM

    Hey there, we in APPresto launched to help people create apps in a faster and easier way.
    Today 91% of the adult population is using smartphones to get information about businesses,
    but only 8% of companies can provide quality mobile app for their costumers. Be modern. Get what you want faster.

    ReplyDelete

Subscribe to: Post Comments (Atom)