Does anyone else find that TeaTimer is possibly the worst resource hog there is? At first boot it was happily sat on 100mb of ram and while it takes very little in the way of process time, the ram just increases and increases - after 5 minutes it's sat at 150mb and after a day or so's working it's well over 250. Fortunately it's on a system with 4 gig here, but on my smaller machine it still tops out around 200mb and that's crippling for a system with only 512 in total. What is it, in the software, that causes such a veracious appetite for memory? Does it load it's entire malware database into ram?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
TeaTimer is a serious resource hog
- Thread starter coyoteboy
- Start date
spybotsandra
New member
Hello,
When the computer is running for a long time without a standby, reboot, or shutdown memory consumption of a (refers to any) can slightly increase.
It's taking that much because TeaTimer is a Resident Shield that actively protects you from malware. I would suggest you reboot and see how it goes. Usually TeaTimer will take up 35-50MB of RAM. Seeing that modern PCs built today have more RAM and resources, 80MB should be nothing.
If this does not help you can disable TeaTimer as follows:
- Go into Spybot - Mode - Advanced Mode - Tools - Resident.
- Uncheck the following: Resident "TeaTimer" (Protection of over-all system settings) Active.
Best regards
Sandra
Team Spybot
When the computer is running for a long time without a standby, reboot, or shutdown memory consumption of a (refers to any) can slightly increase.
It's taking that much because TeaTimer is a Resident Shield that actively protects you from malware. I would suggest you reboot and see how it goes. Usually TeaTimer will take up 35-50MB of RAM. Seeing that modern PCs built today have more RAM and resources, 80MB should be nothing.
If this does not help you can disable TeaTimer as follows:
- Go into Spybot - Mode - Advanced Mode - Tools - Resident.
- Uncheck the following: Resident "TeaTimer" (Protection of over-all system settings) Active.
Best regards
Sandra
Team Spybot
Hi Sandra,
The values I gave above are after a fresh reboot - 100mb "initial", moving to 150 after a few mins, then after a week or so without a reboot it's up in the 200s. I'm aware of its resident nature but I struggle to see (obviously without being one of the programmers) how it manages to consume so much - it's using more resources than all my other non-windows resident packages together and currently more than the full 3D cad modelling package (until I run a CFD analysis!). I understand that on a fairly modern system 150mb is only 3-6% of total RAM (pretty high baseline use for a resident package), but I don't think availability of ram should lead to coding that assumes it's available and wastes it?
I'm curious more than anything else, I've removed it from a couple of my machines as it simply wasn't worth the performance hit, what is the cause of the high ram use? It being a resident process doesn't specifically require high ram use. It seems to take big increases with each successive opened package, despite closing them again, to a point of around 147mb, then increase ~100k per time after that, as though ram is being allocated but never de-allocated until a set level?
The values I gave above are after a fresh reboot - 100mb "initial", moving to 150 after a few mins, then after a week or so without a reboot it's up in the 200s. I'm aware of its resident nature but I struggle to see (obviously without being one of the programmers) how it manages to consume so much - it's using more resources than all my other non-windows resident packages together and currently more than the full 3D cad modelling package (until I run a CFD analysis!). I understand that on a fairly modern system 150mb is only 3-6% of total RAM (pretty high baseline use for a resident package), but I don't think availability of ram should lead to coding that assumes it's available and wastes it?
I'm curious more than anything else, I've removed it from a couple of my machines as it simply wasn't worth the performance hit, what is the cause of the high ram use? It being a resident process doesn't specifically require high ram use. It seems to take big increases with each successive opened package, despite closing them again, to a point of around 147mb, then increase ~100k per time after that, as though ram is being allocated but never de-allocated until a set level?