Memory leak within canvas about vizceral HOT 10 CLOSED

Did some more testing with the Chrome memory profiler and I'm seeing the memory increase during each new graph draw (graph update). I'm doing this (keep in mind Angular services keep state in memory):

// Angular service:
this.viz = null;

this.updateVizceral = function(data) {
   this.remove();
   if (this.viz === null) {
      this.loadVizceral(data);
   } else {
      updateData(data);
   }
};

this.loadVizceral = function(data) {
   if (!angular.element('#graph').html( )) {
      var graph = "<canvas class='vizceral' id='graph'></canvas>";
      angular.element('#graph-parent').append(graph);
   }
   var canvas = angular.element('#graph');
   var canvasWidth = canvas.clientWidth;
   var canvasHeight = canvas.clientHeight;
   this.viz = new Vizceral.default(canvas);
   this.viz.updateData(data);
   this.viz.setView();
   this.viz.animate();
   resize(canvas, canvasWidth, canvasHeight);
};

this.remove = function() {
   if (this.viz) {
      this.viz = null; // mark as removed for garbage collector
   }
   angular.element('#graph').remove();
};

The #graph is the canvas element contained within the #graph-parent.

The native updateData(data) should never be invoked since remove sets this.viz to null. The updateVizceral gets invoked with new API data for the selected graph and updates (generates) a new Vizceral graph with the new graph data. The API data returned from our REST endpoint contains the nodes, edges, and graph name. This works for our UI but the memory leak is definitely present.

from vizceral.

It appears you're trying to create and destroy vizceral objects. I would not recommend reusing the same canvas for every different vizceral object. I would recommend destroying the canvas and creating a new canvas anytime you want to create a new vizceral object.

That being said, destroying and creating vizceral objects multiple times was never a use case we considered, so there will probably be some leftover WebGL shaders and textures hanging around that aren't getting cleaned up properly.

from vizceral.

@jrsquared I appreciate your response but if I have a bunch of disconnected graphs that must be displayed, then what would be a better approach? Rather than having every sub-graph on one large, canvas where the number of nodes will approach 300 and eat up a ton of of the CPU/GPU time, we found that isolating these subgraphs and allowing a user to select what graph to display from a drop down menu was most beneficial. It seems to me like you're use case is that you have a graph with at maximum 75 nodes, and that is the only graph you need to visualize correct? Is the graph cyclic? I'm just trying to get a sense for what kind of a foot this shoe (i.e. Vizceral) can fit. Also I am destroying the entire canvas from the DOM every time a user clicks on a new graph to display from the menu with:

angular.element('#graph').remove(); // there is a canvas directive with the id of 'graph'

Essentially I'm just doing a massive tear down and reconstruct (redraw) of the graph based off of the new nodes and edges.

Also you mentioned, "there will probably be some leftover WebGL shaders and textures hanging around that aren't getting cleaned up properly." Could you please look into this and possibly clean up the potential objects that are still in the heap? I'm not saying there are any, but due diligence must be given to ensure these objects are removed. What happens when a user navigates to another view and those objects are still occupying system resources? Obviously we wouldn't want to impede the users experience. Thank you so much for your time and effort on this phenomenal graph software.

from vizceral.

We have multiple graphs of 100-200 nodes, with another graph for each node being loaded into a single vizceral object. Effectively ~600 graphs that can be navigated between each other; very similar to vizceral-example, just larger.

That is very interesting. They may be a memory leak when destroying vizceral and maybe it should have an explicit teardown function. Please let me know what you find!

from vizceral.

I'm testing in Firefox 40 and Chrome 40. I have managed to get the graphs to load properly but each reload, slows down the animated tics between nodes and eventually Firefox cores. Seems like there's something or things lying around and I'll keep looking through it. I prefer Chrome to FF because of Chromes impressive memory profiling tools, but most of our users are using Firefox, so I may need to profile with Chrome and then reexamine Firefox. Wow you guys are taking on more I thought! I wonder if I updated to a stronger PC with the most recent Chrome if things would go smoother for me. I'm sure they would but unfortunately we are developing to FF 30-40 and our users are mainly using Linux CentOS 6 on PC's that get the job done but are certainly not beefy systems.

from vizceral.

@jrsquared How hard would it be to create an explicit teardown function? Perhaps have something so that we can do the following:

this.remove = function() {
   if (this.viz) {
     this.viz.teardown(); // explicitly tear down Vizceral WebGL objects
      this.viz = null; // mark as removed for garbage collector
   }
   angular.element('#graph').remove();
};

from vizceral.

It probably wouldn't be too difficult, I look forward to your pull request.

from vizceral.

Ha! Well... I'll see if I can get around to it. To be honest, I'm terrified of messing something up the Vizceral source. I'm in grad school and have a bunch of other stuff going on. I am seeing a bunch of destroys in the code base so I suppose I can start going through those. 👍

from vizceral.

Have no fear! The PR review process will help prevent you from messing something up :D We look forward to the contribution.

from vizceral.

@aaronblohowiak so far my time is maxed but yes if I do get around to it post grad school I'll check it out. I found for the time being that a page refresh on each click works for me. It's a bit sloppy and the user will notice a page reload but it does work. I'll have to put this ticket on my TODO list along with PhantomJS based unit tests with Karma and Gulp code coverage. 👍

from vizceral.