2

My app consists of a shell view which loads sub views within it using knockout's templating engine. All the views are built on knockout.

When navigating between views, the value of an observable changes indicating that a new view needs to be bound to a template.

I've packaged the app into an exe using node webkit and it is apparent that RAM usage keeps increasing when I switch views. Memory is only released when the app is closed.

Any idea what red flags I should be looking out for in the code which may be causing this leak and what tools could help me pinpoint the issue?

Chris
  • 21
  • 1
  • Take a look at [this](http://www.knockmeout.net/2014/10/knockout-cleaning-up.html). Is it possible to provide a jsfiddle deomonstrating the memory leak? – Wayne Ellery Jan 13 '15 at 00:36
  • Hey Wayne, I came across that post but I could not understand when or how the dispose method should be called and whether it needs to be called explicitly or not. I also removed all subscriptions in the view and memory still shot up. Do you think this may be more relevant: http://www.knockmeout.net/2012/04/knockoutjs-performance-gotcha.html ? – Chris Jan 13 '15 at 00:45
  • 2
    Without seeing code It's very difficult to diagnose the memory issue. It all depends on what code you have used. Are you using subscribe, computed observables, event handlers or custom bindings? – Wayne Ellery Jan 13 '15 at 00:48
  • I'll try and get a fiddle up later. The views however contain observable arrays constantly updated buy a long poll to the server. The UI has a foreach binding to these observable arrays. – Chris Jan 13 '15 at 00:53
  • Would you suggest any tools to help me narrow down the possible causes of the leak? – Chris Jan 13 '15 at 00:55
  • 2
    That could be what's causing the memory leak. One way to diagnose, is to try to keep removing code until you notice the memory not going up, then you will work out where the memory leak is. Have you tried using the [chrome memory profile tools](https://developer.chrome.com/devtools/docs/javascript-memory-profiling) – Wayne Ellery Jan 13 '15 at 00:56
  • Cool stuff, thanks Wayne will try this out and revert! – Chris Jan 13 '15 at 01:02
  • Sorry about the delay on this, but it turns out that this was not really a memory leak (well sort of). After several weeks of very frustrating investigations, we concluded that while memory was increasing when navigating between views, GC actually kicks in after a while and some (NOT ALL) of the memory is released. We were not able however to identify, when the GC would kick in and why it was kicking in at such long intervals. We also could not identify what was causing the memory to increase between views but in the end we pinned it down to orphaned HTML DOM elements bound with KO. – Chris Mar 18 '15 at 16:07
  • Glad you got it sorted – Wayne Ellery Mar 18 '15 at 22:23

0 Answers0