Continuous Memory Leak in Ember 1.0.0 RC3

1

Hi,

I am analysing ember to use in one of my project. Memory is one of the key concern for final selection.

To validate it, I have created a test application with two routes and without templates.

Chrome profile tools (heap snap shots & memory timeline) indicate that we have continuous memory leaks.

I am attaching the code snippet below for your reference and would appreciate your help if you could indicate whether the issue is with ember or in the way I have created the test application.

Thanks & Regards,

Suresh Gopathy

App.JS

var MyApp = null;

var favView = null;
var blockView = null;

console.log("SGO: App Main Invoked");

MyApp = Ember.Application.create(
    {
        ready: appInit,
        LOG_TRANSITIONS: true
    }
);

MyApp.ApplicationController = Ember.Controller.extend(
    {
        init: function ()
        {
            this._super();
        }
    }
);

MyApp.ApplicationView = Ember.View.extend(
     {
        init : function()
        {
            this._super();
        }
     }
);

MyApp.Router.map(routerInit);

document.addEventListener("keydown", eventHandler, true);

var idTimer = null;

function eventHandler(event)
{
    if (event.which == 65)
    {
        idTimer = setInterval(runFunction, 300);
    }
}


function appInit()
{
    console.log("SGO: AppInit Invoked");
}

function routerInit()
{
    console.log("SGO: Router Init Invoked");
    this.route('fav', {path: '/'});
    this.route('block', {path: '/block'});
}


var routeName = "block";
var iCnt = 50; // Change this value to increase the no of transition.

function runFunction()
{
    MyApp.Router.router.transitionTo(routeName);
    if (routeName === "block")
    {
        routeName = "fav";
    }
    else
    {
        routeName = "block";
    }

    if (iCnt <= 0)
    {
        clearInterval(idTimer);
    }
    else
    {
        iCnt--;
    }
}

MyApp.FavRoute = Ember.Route.extend(
    {
        enter : function()
        {
            this._super();
        },

        exit : function()
        {
            this._super();
            favView.destroy();
        }

    }
)

MyApp.FavController = Ember.Controller.extend(
    {
        init: function ()
        {
            this._super();
        }
    }
)

MyApp.FavView = Ember.View.extend(
    {
        init: function()
        {
            this._super();
            favView = this;
        },

        destroy : function()
        {
            this._super();
        }
    }
)

MyApp.BlockRoute = Ember.Route.extend(
    {
        enter : function()
        {
            this._super();
            blockView = this;
        },

        exit : function()
        {
            this._super();
            blockView.destroy();
        }
    }
)

MyApp.BlockController = Ember.Controller.extend(
    {
        init: function ()
        {
            this._super();
        }
    }
)

MyApp.BlockView = Ember.View.extend(
    {
        init: function()
        {
            this._super();
        },

        destroy : function()
        {
            this._super();
        }
    }
)

MyEmberApp.html

My Ember App 
<script src="libs/jquery-1.9.1.js"></script>
<script src="libs/handlebars-1.0.0-rc.3.js"></script>
<script src="libs/ember-1.0.0-rc.3.js"></script>
<script src="libs/ember-data-latest.js"></script>
<script src="App.js"></script>

This is My Ember App to validate Memory Leeks in Ember
2

I’m new to Ember.js and new to running tests in it. I have your test application running, and I’ve taken a look at the heap snapshots and the memory timeline. But I’m still trying to learn how to use these, so I don’t yet know how to spot a memory leak. If you can help me learn that, I will see what I can see when I test your application. Thanks.

3

Hi Suresh,

I’ll try to look into your code later, but at a first glance I would say that it’s probable that the memory leaks are due to your code and not Ember, manual calls to destroy, using setTimeout, accessing the router from outside the App seems at least non emberish to me.

I’m relatively new to the framework and I normally use the profiler on my apps, so far the only leak I found was actually due to a bug in chrome (already resolved).

Hope to be able to give you a more detailed answer later.

Mat

1 Like
4

It’s a bit of an odd test. I realizing testing memory leaks is hard, but if you’re storing references to this and calling destroy yourself when in a real Ember app you don’t do that, I’m not sure it’s a correct test.

This in particular seems weird. You’re saying this in a Route and assigning it to a variable named view? Wouldn’t this point at the Route not the View?

5

Hi All,

Since there were leaks and views are initialized during every route change (transition), I added the extra code to explicitly call view.destroy which is mentioned in some of the blogs.

Also, the leaks where getting evident when the no of transition increases. Hence added the timer to simulate the transition. You can also try manual route changes using browser forward and backward but still we see growing heap.

Mat, you mentioned it could be because of my code. Could you please pin point the details (except the destroy and timer for which I have added my explanation here)

Thanks

Suresh

6

@suresh_gopathy I see, I’m quite busy atm, but I’ll try to put together a jsFiddle and look deeper into this.

will keep you posted