beta1 and beta2 memory consumption

[IkerAriz]

Memory consumption of v22.beta1 wrt to the latest v22 appears to have improved. Specifically, the workspace which regularly hit 1.5GB+ after a two or three days under v22 (as I reported previously) seemed to stabilize at ~750MB with v23.beta1. However, with v23.beta2 memory consumption over (approx) the same period reached ~1GB.

NB: the memory figures for beta 1 and 2 were over roughly the same period and roughly the same usage pattern. It'd be nice if these reports could be more precise.

Any chance beta3 can supply a facility to report memory-related stats? Or perhaps some usage stats to help make comparisons of memory reports more meaningful? (editing time, num files opened/closed, total size of files opened/closed, max editor tabs, etc).   

Thanks,
Iker

[Dan]

Beta 2 has a whole new diff engine that affects everything the diff uses (including things you don't see, like Backup History).  We use it pretty constantly, so if it were leaking very much I think we'd notice it.  But it is new code and therefore suspect.  Have you diffed or saved any VERY large files (>=50M)?, or run hundreds of diffs (like using Compare with Workspace or multi-file diff).

[IkerAriz]

I may have done two or three diffs when I was running beta 2 but they were not that large (probably less than 10k).

Does SE provide a way to log "interesting" events (opens, closes, diffs, etc)? When I run short experiments to gather info for a bug report I try to write these down as I go along but this isn't practical for issues that come up in regular/extended usage.

Iker

[Dennis]

1GB is a reasonable amount of memory, so I wouldn't worry unless memory usage climbs above the 3GB range regularly.  We fixed several memory leaks for v23, but we did not remove any of the performance caching. 

There are a number of options you could tune down if you want to run a low-memory instance of SlickEdit, the foremost being the tag file cache size.  Search in the options GUI for "cache" or "maximum" to find others.  They are all documented.

My current instance v23 beta2 instance on macOS has been running for over two days, doing heavy C/C++ coding, memory usage is 1.45G, I have caching options turned up above default values for fastest performance.

[IkerAriz]

One option I hadn't looked at carefully before was the number of SE memory allocators. Dropping that parameter to 2 significantly reduces memory consumption: after 5 days of continuous python and C++ editing beta4 is at ~600MB vs 1GB+ with beta2 (and a lot more with v22). Memory slowly crept up to that value so its possible SE may not hold the line there but things seem relatively steady at the moment. As for performance, I haven't noticed any impact.

Iker

[Clark]

Having more allocators helps if your computer has more cores and you are retagging many files. Typically just the current file gets retagged a lot. You should be fine with that setting.