SpEyeGaze - Performance Implications (ram usage)?

[joncamp]

Recording disabled - ~27MB steady state

Recording enabled - Balabolka running, text recording only - ~30MB steady state

Recording enabled - balabolka running, text and screenshots recording - up to 2.8GB

[TeamGleasonDev]

It looks like GC is taking care of this, so these are temporary allocations and not leaks. Give it a shot with the memory profiler of VS if you want to know more, I started using this recently and it's not bad.

We can add a manual GC.Collect() to manage this a little more agressively. Generally this is considered to be an anti-pattern, as it drives up CPU usage in order to save on RAM which the GC has determined is plentiful, so it increases overall system inefficiency.

That said, I too hate seeing graphs like this and suspect that doing a little manual GC.Collect cleaning is a good thing, and even the discussions on it (from long ago) had the caveat that in some situations (mostly after the teardown of a huge tree of small objects) GC.Collect can be warranted.

[joncamp]

Yeah, no disagreement that the GC is doing it's job based on the sawtooth pattern. More concerned that it was all too happy to gobble up 2+GB of ram before doing so. Since Eye Gaze machines are usually not the best spec'd I figured I would call it out. Overall if the performance is fine on the end user system then this is a non-issue. On my dev box I was seeing slow performance, but that may be related to other resource hogs (such as Teams and Defender) or the fact that my 3-monitor setup produces very large bmps/jpgs

In an unmanaged world I would think we would keep a buffer around the size of one screen capture and just reuse that, but this is managed land. Need to stop worrying and trust the GC I suppose.