Memory leaks and how one snuck by us
The most frequent feedback we’ve received from our newest users, has been how much memory the dashboard ties down, just running on it’s own with no activity. Blogs, articles, Twitter, email, we’ve heard it again and again and again. We knew we had some memory leaks when we went to unveil nomee at Web 2.0 expo, but we weren’t expecting the amount of complaints about memory we received.
The good news is, that we’re pretty certain that we solved the memory leak most of our newest users have been experiencing. Bad news is, that I have no idea how they solved it.
But that’s okay! Here’s a few paragraphs from Chris, one of the developers here at nomee.
We had been spending most of our effort tracking down and attempting to fix a bug in the nomee card window. It appears that there are automatic memory leaks when opening and closing any window, but the more content that is added to a window, the more it leaks. Since nomee cards are the most opened and closed windows, we were focusing on improving that.
I was doing some testing unrelated to memory leaks, when I noticed the application getting slower and slower. I popped open the task manager and noticed that the application was hemmorhaging memory. Completely idle and memory usage grew to 400 MB in a matter of minutes. This wasn’t a user-initiated leak that could have occurred by opening and closing cards, it just kept growing.
I started a new session with the nomee application and tried to recreate what happened by retracing my steps. Nope, it wasn’t the profile editor. It didn’t have anything to do with creating a new group and dragging several contacts around. Then, Bingo! When I sent a nomee card, the memory bleeding started again.
Once I got to that point, it was really an easy fix. We have a custom button control that animates while an action is in progress, like a progress bar and button all in one. The send card window was being closed without telling the button to stop animating. Why this caused a leak is related to the previously noted problem with all windows’ affinity for holding on to certain children even after they should have been closed, released, and garbage collected.
Solution: loadingButton.loading = false, THEN this.close()
That explained how brand new users were reporting memory leaks. The primary culprit just couldn’t have been the leak in the nomee card itself, since new users didn’t have enough cards to open and close to ever see that problem. It finally made sense. New users completed the wizard and memory spiralled out of control.
There you have it. Fatal memory leak = solved. We’re still working on the nomee card leak, but it’s relatively minor in comparison. We hope to have a fix for that soon. In the mean time, try it out! Let nomee download the latest update, send a nomee card, see if those memory leaks are still going.
April 15th, 2009 at 3:29 pm
Great catch, I was wondering why I slowed down so much and caught the memory usage. I didn't know it was related to the cards opening and closing. I will go check for an updated client