CODEWITHSUNDEEP
javascriptnode.jsecmascript-6electronv8
Slbox
Slbox

Reputation: 13128

How can I ensure Electron windows are removed from memory entirely?

I know garbage collection is a weak point of JavaScript, but I'd like to do this as best as I can.

I'm creating new windows from my renderer process using remote as opposed to from the main process, which I suspect my complicate cleanup further. If this is a substantial issue, I'm fine with creating them from the main process.

Here's how I'm creating windows now:

import { remote } from 'electron';

function openInternalImageViewer(url) {
  let imgViewer = new remote.BrowserWindow()
  imgViewer.loadURL(url);
}

Is simply setting the imgViewer variable to null after closing the window via the provided APIs sufficient to achieve my ends, or are my suspicions that I need to do more correct?

Upvotes: 5

Views: 1327

Answers (1)

jmrk
jmrk

Reputation: 40521

You can't directly ensure that JavaScript objects are removed from memory. You simply get rid of all references you no longer need, which allows the garbage collector to do its work. (I wouldn't call that a "weak point" -- compared to having to do manual memory management, it's a strength of JavaScript that it does all that work for you.)

You don't have to worry about function-local variables: when the function returns, the variables go out of scope anyway. "Clearing" them manually right before that accomplishes nothing. Example:

function openInternalImageViewer(url) {
  let imgViewer = new remote.BrowserWindow()
  imgViewer.loadURL(url);

  /* ...let user interact with imgViewer... */

  imgViewer = null;  // Useless assignment.
}

This is true for both let and var variables.

Of course it's different for global variables (but of course you shouldn't have many of these):

var imgViewer;

(function openInternalImageViewer(url) {
  imgViewer = new remote.BrowserWindow()
  imgViewer.loadURL(url);
})(some_url);

/* ...let user interact with imgViewer... */

imgViewer = null;  // This cleanup makes sense!

/* program execution continues, imgViewer no longer needed */

From the engine's point of view, it doesn't matter whether you assign null, undefined, or 123, so you can choose whichever value makes the most sense for you.

Also, it doesn't make a difference where something was created/allocated from. What matters for garbage collection is whether or not an object is "unreachable", i.e. there's no way for your code to ever get to it again.

To verify whether it works, you have to use some sort of memory analysis/profiling tool. The simplest form is to use your operating system's task manager. Write a test roughly like:

for (var i = 0; i < 100; i++) {
  openWindow();
  closeWindow();
}

and watch whether the memory consumption of all involved processes keeps returning to its original value. It probably won't do that immediately, instead you'll see a "sawtooth" pattern where memory keeps growing until the GC kicks in and brings it down again. You can consider forcing GC cycles manually in the test; just be aware that in production code, that would be a waste of time, as the automatic GC behavior has very carefully tuned heuristics to balance the time spent on garbage collection against the available memory.

Upvotes: 4

Related Questions