sebhildebrandt/systeminformation

Perf: re-use / cache utility processes (wmic...)

GitSquared opened this issue · 1 comments

Is your feature request related to a problem? Please describe.
Most notably on Windows, utility processes are launched for each data-retrieval op, which can cause issues when refreshing data frequently (threads/memory starvation from the "cloud" of small short-lived processes).

exec(WINDIR + '\\system32\\chcp.com 65001 | ' + getWmic() + ' ' + command, options, function (error, stdout) {

Describe the solution you'd like
Perhaps we could cache/re-use some of those processes to avoid the overhead of launching them on each call?

Pseudo-code for how this could work, in the context of the wmic() util function linked above:

let cached
let t

fn wmic(command)
	if (!cached && !cached.alive)
		cached = startWmicProcess()

		// Kill the process to free ram if it hasn't been used for 3s
		t = timeout(cached.kill(), 3000)
		// Kill the process on SIGTERM to allow node to exit
		node.onExit = cached.kill()

		return cached.send(command)
	else
		// Keep process alive
		resetTimer(t)
		return cached.send(command)

Of course this would only work for processes where we can get a CLI running and send multiple commands over time.

What do you think? I've done similar work in one of my recent projects, although that was with WebWorkers, not Node.js child processes, but I'd be willing to look into making a PR if you want.

Additional context
(Related: #229)

@GitSquared totally understand what you mean. But as the different commands may use different time frames to execute and the "validity" of certain values may be different for command, a fixed value here in the util.wmic() function is not really an option. I left this up to the developer/consumer of the package to define the time intervals and I think, depending on the use case everybody would handle this differently. Therefor I would like to leave it like it is for now. OK?