Memory issues (leak?)

[Michelle911]

Since 4.1 I've been experiencing some pretty major memory leakage on my windows7 x64 system. I don't play games or run anything in fullscreen modes (pc is my daw system). I have 24gigs of ram and I usually have <20% in use when idle and about 30% (give or take) with daw and a simple project loaded. Since 4.1 (and now much worse in 4.2) it slowly climbs to over 50% usage in these circumstances. Not sure if it's a "leak" by definition because it's mostly recoverable by quitting rainmeter.

Skins in use are :

• WXDataWeather
• ABP\System CPU
• Simple Media\DateTime
• VolKnob

That's it, just these four.

I read in an old post that installing Rainmeter in portable mode helps but I'm already running in portable mode. I read in another Memory Leak thread about Raingame, but like I say I'm not gaming or running anything in fullscreen. Didn't see anything else so hopefully this is deserving of its own thread.

Thanks
☮

[balala]

Do you know when have you installed those skins? Because I used the 4.2 version of Rainmeter (in the meantime I updated to the latest 4.3) and had no such issues. But I didn't use any of the enumerated skins and I think the skins was installed approximatively when you upgraded Rainmeter. So basically the issue is caused not by the newer Rainmeter version, but by one of those skins.
What I'd suggest is to unload the skins, one at a time. After each unload follow the RAM usage for a while, to see how does it change. As I said, I suppose one of the skins is guilty. If I'm right, you'll figure this out after unloading that one. Just take care to leave enough time after each unload.

[Active Colors]

Do you know when have you installed those skins? Because I used the 4.2 version of Rainmeter (in the meantime I updated to the latest 4.3) and had no such issues. But I didn't use any of the enumerated skins and I think the skins was installed approximatively when you upgraded Rainmeter. So basically the issue is caused not by the newer Rainmeter version, but by one of those skins.
What I'd suggest is to unload the skins, one at a time. After each unload follow the RAM usage for a while, to see how does it change. As I said, I suppose one of the skins is guilty. If I'm right, you'll figure this out after unloading that one. Just take care to leave enough time after each unload.

How do you imagine the process when a skin can be guilty causing the RAM increase overtime?
I have several, my own, skins running simultaneously. They are very optimized and have no constant reading or writing or updating or whatsoever. At the start Rainmeter takes around 70mb of ram and increases overtime to 300mb. If I unload all the skins the ram usage drops only by 10-20 mb still consuming ~280mb of ram.
I am using latest 4.2 and I think I recall the same story as the author of this thread. I don't remember that older versions had such a high leak of memory; at least it was not that big comparing to what I see in 4.2.

[jsmorley]

How do you imagine the process when a skin can be guilty causing the RAM increase overtime?
I have several, my own, skins running simultaneously. They are very optimized and have no constant reading or writing or updating or whatsoever. At the start Rainmeter takes around 70mb of ram and increases overtime to 300mb. If I unload all the skins the ram usage drops only by 10-20 mb still consuming ~280mb of ram.
I am using latest 4.2 and I think I recall the same story as the author of this thread. I don't remember that older versions had such a high leak of memory; at least it was not that big comparing to what I see in 4.2.

Be sure you are looking at Working Set Private for memory. That is the only one that really counts. Private Bytes and Working Set are both pools of memory that are allocated in a shared way, and while not immediately released when not being used, are available for other processes as needed.

Windows 10 manages memory is a very different way than Windows 7 did. It is much less interested in "free memory", as it considers that pointless. It is much more interested in using memory in a shared way, keeping memory allocated as allocated, so it can be very quickly accessed again if the same process needs it, while making it instantly available for other processes if needed. The only thing that is more or less allocated and hard-wired to a running process is Working Set Private. Even that isn't immediately returned to free memory when a process stops using it, although it will over time.

I don't have any issue with my 20+ skins running all the time. My Working Set Private is about 40meg, and pretty much stays somewhere around that.

1.png

[balala]

I am using latest 4.2

See jsmorley's very detailed and good explanation above.
But just to mention, 4.2 isn't the latest version, 4.3 is already published on the main site.

[Active Colors]

All right. I've been running rainmeter without any skins on for a couple of days, no memory flaws so far. I admit the problem lays within the used skins.

But just to mention, 4.2 isn't the latest version, 4.3 is already published on the main site.

I meant the latest from 4.2. Cannot run 4.3 on my laptop for now.

[balala]

I meant the latest from 4.2. Cannot run 4.3 on my laptop for now.

I don't understand! If you can 4.2, why cannot 4.3?

[Active Colors]

I don't understand! If you can 4.2, why cannot 4.3?

Glitching with acceleration on, lagging with acceleration off. I can't tolerate that and I have to use 4.2.