4 ms·

>Windows Energy-saving timer heuristics Another example of Windows' technical debt being there, low-hanging fruit-wise, to be cashed in by performance-oriented

by aa-jv 11mo ago

>Windows Energy-saving timer heuristics Another example of Windows' technical debt being there, low-hanging fruit-wise, to be cashed in by performance-oriented developers. Its interesting that Youtube changing the timer resolution propagates to other threads .. does this harken to darker days in the MSDOS era? Youtube, another Turbo button?

fragmede 11mo ago
The best one, of course, is the one where Windows would install faster if you jiggled the mouse.
- jaffa2 11mo ago
  I this related to when you are scrolling and selecting within a document, and you wiggle the mouse, it scrolls faster ? I always thought it was just a nice UI optimisation, but I could believe it's actually some accidental side-effect at play. (like make a 20 page word doc, and start selecting from the first page and drag through - it wil go faster if you jiggle. same in excel and nearly every windows app, even windows explorer)
  - ninkendo 11mo ago
    No, it has to do with every time you move the mouse over a window, a hover event is sent to the application, which runs its main event loop. Either the installer only updated its progress bar when an event happened (in which case it would only appear to be going faster, because the progress bar would move more smoothly) or there was some really terribly written code that literally only made progress when an (unrelated) event happened. My guess is the former.
    - moron4hire 11mo ago
      Being a bored kid in the 90s with nothing better to do, I had timed it. It was actually faster.
    - fransje26 11mo ago
      No, that's not quite correct. It was not giving the impression of being faster, it was faster. https://retrocomputing.stackexchange.com/questions/11533/why-did-moving-the-mouse-cursor-cause-windows-95-to-run-more-quickly https://retrocomputing.stackexchange.com/questions/11533/why...
    - anthk 11mo ago
      IRQ's. It was faster.
  - ygra 11mo ago
    Explanation for that is here: https://devblogs.microsoft.com/oldnewthing/20210126-00/?p=104759 https://devblogs.microsoft.com/oldnewthing/20210126-00/?p=10...
    - jaffa2 11mo ago
      Aha! Thanks for the link. So it is a kind of side effect thing.
  - joshuaissac 11mo ago
    There must be so many subtle features like these that people use subconsciously, and when they try to move to another operating system, they try it, nothing happens and they get frustrated.
- giancarlostoro 11mo ago
  Makes me wonder how much of Windows is like Pokemon glitching, a community that never stops, even several generations ahead.
- fhdkweig 11mo ago
  I was told a story by some hackers in the old multi-user mainframe days. They said that a good speed booster was to have the program open a terminal because it made the mainframe OS think it was a real-time user interactive program and give it more resources.
  - aa-jv 11mo ago
    I still have the brainwash/muscle-memory to type: $ gunzip -c somefile.tar.gz | tar xvf - .. because there was, once, a day when the terminal buffer available for this pipe was bigger than available memory offered to a process by default, meaning the thing would unpack faster if I did that versus: $ tar zxvf somefile.tar.gz Admittedly, this discrepancy of available memory was usually because the BOFH hadn't realized there was also an allocation for pipes-per-user, so it was a neat trick to get around the hard limits that BOFH had imposed on some of my processes in terms of heap allocation ..
antonvs 11mo ago
A performance issue related to this is more likely a shortcoming in the software experiencing this issue. The setting in question is the minimum timer resolution. Changing this will only have an impact on applications that depend heavily on that resolution, i.e. it's not some sort of turbo button for general execution speed. In fact according to the docs, a higher resolution can "reduce overall system performance, because the thread scheduler switches tasks more often." An application whose performance depends on the timer resolution should be setting that resolution itself, using the Win32 API function mentioned in the thread, timeBeginPeriod, which includes the following in its documentation: > For processes which call this function, Windows uses the lowest value (that is, highest resolution) requested by any process. For processes which have not called this function, Windows does not guarantee a higher resolution than the default system resolution. > Starting with Windows 11, if a window-owning process becomes fully occluded, minimized, or otherwise invisible or inaudible to the end user, Windows does not guarantee a higher resolution than the default system resolution. See SetProcessInformation for more information on this behavior. > Setting a higher resolution can improve the accuracy of time-out intervals in wait functions. However, it can also reduce overall system performance, because the thread scheduler switches tasks more often. High resolutions can also prevent the CPU power management system from entering power-saving modes. https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod https://learn.microsoft.com/en-us/windows/win32/api/timeapi/...
- aa-jv 11mo ago
  Thats all well and good, but this part seems a bit .. uninformative, or at the very least, easily misunderstood by the harried developer: >For processes which have not called this function, Windows does not guarantee a higher resolution than the default system resolution. There should at least be mention that changing this resolution can effect other processes. Is this a bug? Its hard to see it as a feature.
  - ninkendo 11mo ago
    > There should at least be mention that changing this resolution can affect other processes. That sorta is what it’s saying. If you don’t set it yourself, you won’t get any better than the “default system resolution”. But if the default system resolution changes (say, by entering a sort of “performance mode” when playing games or watching videos), then it would imply it will affect all processes that are using the default, right?

by aa-jv 11mo ago

fragmede 11mo ago

The best one, of course, is the one where Windows would install faster if you jiggled the mouse.

jaffa2 11mo ago
I this related to when you are scrolling and selecting within a document, and you wiggle the mouse, it scrolls faster ? I always thought it was just a nice UI optimisation, but I could believe it's actually some accidental side-effect at play. (like make a 20 page word doc, and start selecting from the first page and drag through - it wil go faster if you jiggle. same in excel and nearly every windows app, even windows explorer)
- ninkendo 11mo ago
  No, it has to do with every time you move the mouse over a window, a hover event is sent to the application, which runs its main event loop. Either the installer only updated its progress bar when an event happened (in which case it would only appear to be going faster, because the progress bar would move more smoothly) or there was some really terribly written code that literally only made progress when an (unrelated) event happened. My guess is the former.
  - moron4hire 11mo ago
    Being a bored kid in the 90s with nothing better to do, I had timed it. It was actually faster.
  - fransje26 11mo ago
    No, that's not quite correct. It was not giving the impression of being faster, it was faster. https://retrocomputing.stackexchange.com/questions/11533/why-did-moving-the-mouse-cursor-cause-windows-95-to-run-more-quickly https://retrocomputing.stackexchange.com/questions/11533/why...
  - anthk 11mo ago
    IRQ's. It was faster.
- ygra 11mo ago
  Explanation for that is here: https://devblogs.microsoft.com/oldnewthing/20210126-00/?p=104759 https://devblogs.microsoft.com/oldnewthing/20210126-00/?p=10...
  - jaffa2 11mo ago
    Aha! Thanks for the link. So it is a kind of side effect thing.
- joshuaissac 11mo ago
  There must be so many subtle features like these that people use subconsciously, and when they try to move to another operating system, they try it, nothing happens and they get frustrated.
giancarlostoro 11mo ago
Makes me wonder how much of Windows is like Pokemon glitching, a community that never stops, even several generations ahead.
fhdkweig 11mo ago
I was told a story by some hackers in the old multi-user mainframe days. They said that a good speed booster was to have the program open a terminal because it made the mainframe OS think it was a real-time user interactive program and give it more resources.
- aa-jv 11mo ago
  I still have the brainwash/muscle-memory to type: $ gunzip -c somefile.tar.gz | tar xvf - .. because there was, once, a day when the terminal buffer available for this pipe was bigger than available memory offered to a process by default, meaning the thing would unpack faster if I did that versus: $ tar zxvf somefile.tar.gz Admittedly, this discrepancy of available memory was usually because the BOFH hadn't realized there was also an allocation for pipes-per-user, so it was a neat trick to get around the hard limits that BOFH had imposed on some of my processes in terms of heap allocation ..

antonvs 11mo ago

A performance issue related to this is more likely a shortcoming in the software experiencing this issue. The setting in question is the minimum timer resolution. Changing this will only have an impact on applications that depend heavily on that resolution, i.e. it's not some sort of turbo button for general execution speed. In fact according to the docs, a higher resolution can "reduce overall system performance, because the thread scheduler switches tasks more often." An application whose performance depends on the timer resolution should be setting that resolution itself, using the Win32 API function mentioned in the thread, timeBeginPeriod, which includes the following in its documentation: > For processes which call this function, Windows uses the lowest value (that is, highest resolution) requested by any process. For processes which have not called this function, Windows does not guarantee a higher resolution than the default system resolution. > Starting with Windows 11, if a window-owning process becomes fully occluded, minimized, or otherwise invisible or inaudible to the end user, Windows does not guarantee a higher resolution than the default system resolution. See SetProcessInformation for more information on this behavior. > Setting a higher resolution can improve the accuracy of time-out intervals in wait functions. However, it can also reduce overall system performance, because the thread scheduler switches tasks more often. High resolutions can also prevent the CPU power management system from entering power-saving modes. https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod https://learn.microsoft.com/en-us/windows/win32/api/timeapi/...

aa-jv 11mo ago
Thats all well and good, but this part seems a bit .. uninformative, or at the very least, easily misunderstood by the harried developer: >For processes which have not called this function, Windows does not guarantee a higher resolution than the default system resolution. There should at least be mention that changing this resolution can effect other processes. Is this a bug? Its hard to see it as a feature.
- ninkendo 11mo ago
  > There should at least be mention that changing this resolution can affect other processes. That sorta is what it’s saying. If you don’t set it yourself, you won’t get any better than the “default system resolution”. But if the default system resolution changes (say, by entering a sort of “performance mode” when playing games or watching videos), then it would imply it will affect all processes that are using the default, right?