[Feature]: Concurrency for the script

[Paladynee]

Problem statement

I am skimming through the resulting script from the Standard preset for Windows. Looking for a culprit responsible for the low performance, and the first educated guess is most tweaks firing up a powershell instance. Sure, it works good enough but we can do better by leveraging concurrency for the tweaks, since none (or a negligible amount) of the tweaks depend on each other.

Proposed solution

approach 1

The implementation is up to the developer, however, a simple framework could be one that generates subscripts of privacy.sexy in a child folder in the current working directory and spreads tweaks evenly between many scripts. The "amount of tweaks" surely isn't a good metric to approximate the resulting performance but it will be good enough™. Then, we can fire up multiple child processes that run these split-scripts for more concurrency, possibly leveraging more threads.

approach 2

However, if approach 1 does not work, or the tweak code generation is different, a queue approach can be taken. We will open some amount of child processes, and each process will access a specific tweak using the process index from a shared queue, and then run those tweaks.

• disambiguation

  pseudocode:

  queue[completed_tweaks * total_processes + i] // where i is the current tweak index

  visual example 

Additional information

Resolving the matter of "tweaks that depend on eachother" can be solved by putting tweaks that depend on each other, next to eachother in the same sub-script/queue entry.

Challenges could include code generation for the script, and figuring out the runtime.

The concurrency feature can be added as an optional feature in the web version. It will require a checkbox and optionally a specific amount of processes.

Feature pros and cons

+ Will improve performance on powershell-heavy scripts (and other blocking commands) + Little overhead + Privacy.sexy already uses a script-generator, this can easily be used for the concurrency

- Will not improve performance on CPU bottlenecked targets - Slightly harder to maintain (which tweaks depend on eachother?) - Possible introduction of races

[undergroundwires]

This is great suggestion. I will implement this in a feature release when I have the time (no timelines promised unfortunately due to many TODOs). Thank you @Paladynee.