Sharex: Optimize memory usage while in tray

[dzmitry-lahoda]

It takes 47 MB private bytes sitting in tray on Windows 10

I guess it can do better, e.g. 25 MB.

I have donated 10 USD via Patreon today. Will donate another 10 if memory in tray will reach 5 MB:)

[Jaex]

Only way would be moving memory to hard drive which is not ideal because on first region capture hotkey usage it will open delayed.

[dzmitry-lahoda]

Lazy loading menus and controls. I guess only part of menus-hotkeys used often and must start fast, but all menus-hotkey handlers are hot loaded?

[Jaex]

That memory usage mostly because of .NET Framework. So apps made with .NET Framework always gonna use far more memory than apps made with C++.

[dzmitry-lahoda]

Empty Windows Forms applications takes 13 MB private bytes. I guess ShareX may get something in beetwin (13 + 47) / 2 = 30.
.

E.g. I see that some libs fomr c:\Program Files\ShareX\ are lazy loaded and some not:

Some could be made lazy.

E.g. Remoting, Uploaders, can be lazy, and related classes inside application.

[dzmitry-lahoda]

JSON in tray - 5 MB. Tooltips - 2 MB. May lazy JSON or use other JSON lib. Can may tooltips less heavy and lazy.

[dzmitry-lahoda]

So my estimates are possible - you may reach 30 MB in tray. Could leave issues open for couple days for people to vote so:)

[SC2Mitch]

Does really anyone care that it's 50mb or wtf it is? Mine runs at 100mb and I literally don't care, doesn't affect me and I doubt it affects other users.

[dzmitry-lahoda]

I guess users of git are rich and pay a buck for their tooling - hardware. But most people do not. E.g. I have 5+ people I setup laptops who has 4 GB of RAM with HDD drives. They do care when their laptop becomes slow after tray background applications they eat all memory.

[dzmitry-lahoda]

Also you may bought 8 GB 2 in 1. DDR is energy hungry, so 50 MB commit means - yet another energy leak. Widows memory hungry. Users buy Android or Mac. .NET Desktop dies.

[dzmitry-lahoda]

Last but not least, there are 2 types of program - main and background. Main may eat all my memory - drawing pictures or do spreadsheets.. Background - clipboard and screenshot, music player, hardware monitor.
ShareX for most users is background, sometimes becoming main. This is ideal case for lazy plugin load. Only first usage will pay time. E.g. no 200ms but 100ms for actions. Next uses will pay almost none, e.g. 100ms instead of 99ms with not lazy.

Arithmetic, 50MB * 80 = 4 GB. So max 80 processes making my laptop smart. 30MB * 133 =4 GB. So 133 processes make my system smart. Or more additional space for my main photo editing app.

[XanderLuciano]

50 -> 30mb represents 0.5% of available ram on a 4 gig system and you're suggesting a 50% reduction in background memory usage + a performance hit for the benefit of a small subset of users.

I don't see a compelling reason to significantly reduce memory usage for such a little gain.

That said, I'm not even seeing 50mb in RAM usage on my end (Windows 10, 20gigs of ram, SSD).
ShareX is only using 30-40mb of ram for me.

Sure developers shouldn't just use up all a user's RAM, but if a 20mb difference is what it takes to keep a system from lagging, maybe just go back to using the snipping tool + paint? Or go throw some suggestions towards the Chromium team. There's a software that could really use a reduction in RAM usage.

Plus this software is open source anyways, you're more than welcome to make those proposed changes and create your own custom build with 20mb less ram usage and distribute that to the lower spec'd laptops.

And lastly, I can't image there is a lot of overlap between users who need all of Sharex's features and users on systems with 4gigs of ram. Snipping tool + paint covers most of the basic features.

[dzmitry-lahoda]

There are cool PCs with 4GB of ram. Why do you say they will not use ShareX? Do you know distributions of users and for what purposes use ShareX?

Snipping tool does not video or gif. Paint is awful for editing screenshot images.

Chromium as you mentioned is usually foreground application and does not starts after login. ShareX, until called first time in the day, is background applications which must start after login.

Doing manual changes are not sustainable, because they suggest to make ShareX parts lazy (first calls of each feature is slightly slower, but next are same, not use never get loaded).

Ecosystemically, background tools should use small amount of energy and memory, memory eats energy. Background tool to per good part of default installation chosen by as many as possible should use few resources, until invoked. Lazy architecture allows to better understand whole application and evolve it more easily.

I checked another tool, Greenshot is 1.5X smaller, but no video support.

Another approach would be not to change ShareX, but write proxy shim with tray menus and hotkeys which routes calls to real ShareX, and kills it when not used for long time, but not sure how far and stable it can get.

[ghost]

ShareX is already using less than 30MB on my machine. I'm using ShareX v12.0.0 on Windows 10 with 8GB of RAM.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[bozelllouis]

Built-in roles for Azure resources | Microsoft Docs

https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles?WT.mc_id=email