Hello,

it seems meminfo uses timeBeginPeriod from winmm.dll or NtSetTimerResolution and NtQueryTimerResolution from ntdll.dll functions on the startup to change system-wide timer resolution.
There is no obvious advantage of changing/setting this value when runnning MemInfo. Besides, Meminfo sets it on the startup and doesn't change it until the process ends. With program running on the tray it means it is using 1ms resolution ( instead of default 15.6) all the time. It would seem more bug rather than an optional "feature" or setting.
Would it be possible to either remove those calls, or make them an "option" ?

Thank you.

https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution- megawatts-wasted/

Hi,

Thanks for your report on this issue.

MemInfo uses standard API timer functions to update the tray display and does not in any way change system wide settings.

Did you try changing the tray info refresh rate to a higher value?

I read the article, did some tests as suggested and this "Current timer interval" setting is changed into 1ms after launching different applications (I did several tests after a reboot without MemInfo being executed). In the article it states several known applications "change" this value as well. This seems more like a Windows issue the a MemInfo one. I will however try to obtain more information on this.

Thank you,

André Santos
Carthago Software Support
http://www.carthagosoft.net

That's the problem with timeBeginPeriod in windows - any single call from any application changes system-wide timer resolution setting. It either shouldn't be used at all or used selectively in apps for a few seconds. Still, allowing this is the biggest "hole" in multi-user windows that I've seen so far.
My Meminfo refresh rate is 5000ms. The easiest way to "debug" the issue - although it is obvious that MemInfo calls timeBeginPeriod, is to use - https://github.com/florentchauveau/ClockResIcon
on clean system after bootup, resolution should be 15, starting MemInfo brings it down to 1, and, obviously, it will not change back until application ends.

It is a windows, microsoft issues, no questions - changing code not to call timeBeginPeriod - developer's task. ( being a developer myself).

Not running apps that do those calls will add ( on my moderate testing) - 10-15% to battery life.
Chrome/Firefox seem to have fixed those (Chrome brings timer up while updating page and then restores it back) - but only few month ago. If you "have to" run those apps - there is no choice, if there is a choice - I prefer extra 15% to my battery life.