Bitsum Community Forum

General Category => ParkControl => Topic started by: Nudge on September 30, 2025, 06:49:16 AM

Title: Experimental Profile Switcher
Post by: Nudge on September 30, 2025, 06:49:16 AM
New Experimental Profile Switcher

Works great for me & was exactly what I have been waiting for as the Idle stuff is based on a user rather than CPU load.

Emperically these settings work great for me:

CPU Load Low Profile 30%

CPU Load High Profile 50%

Min Time before Switch 500ms

[Tick] Check load of individual core


As an experimental feature though it appears to only *operate* if ParkControlPro is Minimised or Displayed but not if OK'ed/Closed to the Notification Area. If I restart ParkControlPro from the Notification Area the option appears to require Enabling again even though it is already enabled when checked (experimental option effect maybe?).


Hopefully this will change if feedback is positive & no is longer experimental.


Title: Re: Experimental Profile Switcher
Post by: Jeremy Collake on October 02, 2025, 10:59:53 AM
Thanks for the feedback!

You are correct, it is only active while the ParkControl window is visible. We will get that taken care of and investigate the enabled state inconsistency you observed. I'll reply again here as there are changes.
Title: Re: Experimental Profile Switcher
Post by: Jeremy Collake on October 02, 2025, 05:16:06 PM
As of ParkControl v5.5.1.1 BETA the Power Profile Switcher will function while ParkControl is minimized to the tray.

Regarding the enabled state inconsistency: If you exited from the tray menu while the Power Profile Switcher config dialog is open, then any change to the checkbox wouldn't be preserved. The dialog has to be dismissed first with the "OK" button. Is that what you saw?
Title: Re: Experimental Profile Switcher
Post by: Nudge on October 06, 2025, 10:11:38 AM
The state inconsistancy description I mentioned after further experimenting was misleading (although interesting all the same).

If an enabled Profile Switcher is disabled (unticked & Ok'ed) then the power plan goes back to the power plan before ParkControl was started (as expected & the same as if ParkControl had been exit'ed).

If the now disabled Profile Switcher is enabled (ticked & OK'ed) then the power plan sometimes does not change to one of to the Profile Switcher power plans for a number of seconds (I have observed a 2 second as well as a possibly 8 seconds delay - this is with a minimum time before switch of 500ms). A long delay like 8 seconds probably fooled me into thinking it wasn't restarting (as the power plan hadn't changed hence the need to toggle the Profile Switcher).

Trust this helps.



Title: Re: Experimental Profile Switcher
Post by: Jeremy Collake on October 06, 2025, 04:06:23 PM
Thanks for the clarification! The unexpected delay may have been resolved by the previous adjustments, but we'll be sure to look into it.
Title: Re: Experimental Profile Switcher
Post by: Nudge on October 14, 2025, 10:55:07 AM
ParkControl 5.5.1.8 is a lot more responsive to changing power plans & now does so when not a window (as Jeremy explained).

My other question which is indirectly connected is does this mean the Windows Registry is updated upon each power plan change ?  (I believe the default write (flush) to registry is every 5 seconds & may be extended if desired).

I ask because (as far as I can tell via searching (but yet not empirically)) a Power Plan Change does update the Registry so it may mean numerous writes to an SSD which although small may mean larger Flash block erases to write the small data change.

The usefulness of this feature far outweighs any of the above though in my opinion.

Thanks.
Title: Re: Experimental Profile Switcher
Post by: Jeremy Collake on October 17, 2025, 11:55:12 AM
The registry is written to by the Windows API every time the power plan is switched. That is just where it's stored.

Given the volume of other system activity, it seems unlikely to me that this would cause any significant increase in SSD writes or erase cycles. There's a lot more registry write activity, for instance, that is going on routinely while using your OS. Also, SSDs are a lot more resilient than they once were, so it's not evident if this is even a valid concern these days.

So, I think your conclusion is correct ;).