DISCLAIMER: Due to the nature of discussion following this thread, all content has been omitted except for the instructions provided with the intent of improving the performance of running local applications on the Windows operating system.
There remain no quantitative reports or official benchmark tests to support the author’s arguments, therefore, all of the following information exists as a purely open possibility, and subject to one’s discretion.
From the start menu:
Right click SC
More → Open File Location
Now, for sclang, scsynth, scide & supernova, as well as all application shortcuts leading to them:
Right click → Properties
Compatibility → Run as Administrator
Apply → Ok
Right Click → Repeat
Windows+X → Task Manager
sclang/scsynth → Right Click
Go to Details → Right Click
Set Priority → Above Normal
* Priority level Normal is reset for each spawned process
* Priority level High should be tested in careful isolation
* Priority level Realtime will immediately crash the OS
It’s a useful strategy to view all running processes under:
Users → Current User
Versus viewing all user & system processes inclusively.
Could you provide some information on what performance advantage is achieved by performing these steps?
It should be noted that running applications as administrator is typically not recommended as it poses additional security risk.
As for priority levels - I thought that SC does some priority levels management even under Windows, but I don’t know for sure. Particularly for scsynth, I believe that the audio thread has a different (higher) priority than the main process (or so I thought).
In any case - it’s best if the advice is backed by at least empirical evidence, otherwise it might backfire.
I once empirically & royally crashed Windows immediately upon setting a single process to “Realtime” priority… Never do this.
I was only joking about using Windows.
All jokes aside, I feel the OS fights with SC less when ‘Run as Administrator’ is selected versus a normal run option.
It’s not clear what ‘Run as Administrator’ actually does at this moment… aside from the obvious permission inheritance applied to the specific process on launch.
It is the second in a long list of options shown when right clicking the shortcut to launch an app, and to bind this option to every launch, it’s under the ‘Compatibility’ settings in Properties, along with other miscellaneous & performance related settings.
I’m sure & while this may be correct for SC under the hood, from the perspective of the task manager UI for all running processes & services, all instances of a launched application (a running process) are represented above the hood as having the following options for
All running application processes encounter an initial thread priority value of Normal upon each successive launch.
This remains true for scide.exe, sclang.exe, scsynth.exe, & supernova.exe.
First of all, don’t use the default task manager, use something decent like “Process Explorer” by Sysinternals (Process Explorer - Windows Sysinternals | Microsoft Docs). Then you would see that the priority shown by task manager only applies to the main thread. If you double click on the process you can get a view of all the threads and their respective priorities.
As @MarcinP correctly points out, SC already sets the priority of the audio thread to “time critical”. There is absolutely no point in raising the priority of the main thread because it sits idle until the end of the program (at least on Windows and Linux, on macOS it runs the Cocoa event loop).
Please only give performance tuning advice if you have a thorough understanding of the topic and you can show some empirical data.
Ok, I did a quick test with Process Explorer and I have to correct myself somewhat: raising the priority in Process Explorer raises the priority of all threads with a lower priority.
By default, the network thread and NRT thread have a base priority of 8 and the audio thread has a priority of 15. After manually raising the priority to “High (13)”, the network thread and NRT thread have a priority of 13, but the audio thread still has a priority of 15. This means that the audio thread is not really affected. However, it is a legit question why the network and NRT thread should run at “Normal” priority. I think it should be possible to raise the priority as long as the audio thread still has the highest priority.
@Rainer I am wondering what you mean exactly when you say that after manually raising the thread priority SC seems to run faster. Audio computation can’t be affected, as I have shown. The only things that could run faster is dispatching of OSC messages/bundles (possibly allowing for a smaller Server latency) and execution of asynchronous commands. But for both we would need actual empirical data.
In the meantime, I would appreciate it if you could add a disclaimer to your original post. Your advice to run SC as administrator is certainly bogus and the advice to manually raise the thread priority at least questionable.
Generally, the rule number one for performance tuning is: measure!