High CPU and Memory Usage sporadically, but can't find the pattern

[Nantris]

You can can see in the image below that the memory usage varied wildly by an entire gigabyte up and down in the course of a few seconds, repeating in a pattern. I confirmed the memory usage is being caused by electron-json-storage, though I'm not exactly sure how. You can also see CPU usage was very high, causing freezing and stuttering, and that the offending calls are from electron-json-storage:

The CPU usage and retained memory both appear to occur due to this particular part of the code:

electron-json-storage/lib/storage.js

Lines 384 to 396 in 034b58b

	function (result, callback) {
	fileName = result;
	const data = JSON.stringify(json, null, (options.prettyPrinting ? 2 : 0));
	if (!data) {
	return callback(new Error('Invalid JSON data'));
	}
	// Create the directory in case it doesn't exist yet
	mkdirp(path.dirname(fileName), function (error) {
	return callback(error, data);
	});
	},

I've seen this issue on rare occasions but when it occurs usually the app crashes. Today I finally was able to diagnose which code was behind the issue at least. 5-10 minutes later, the memory usage and CPU usage resolved (snapshot 1 vs 2) below

Specifically the retained memory is a bunch of identical strings. The retainers graphs vary slightly for some of them but the most common one looks like below. In the image below storage.js is the electron-json-storage module and index.js is from mkdirp.

@jviotti do you have any thoughts on what might cause this? Perhaps it could be resolved by replacing mkdirp with the now available Node built-in alternative? Or maybe the issue doesn't truly arise from mkdirp but from the way it's called. I'm not that good at interpreting these heap snapshots and they're tough to revisit later since the codepaths they reference are lost even if you save the heap snapshot to review again later.

[Nantris]

One more screenshot before I restart the app and lose some of the debugging data (the code paths.) You can see the blocking time is almost the entire length of the recorded time in the performance tab (at the bottom of the screenshot)