8

I have observed a curious behaviour where processing in Unity Editor (TestRunner) takes 2.5s while the editor is in the foreground, but slows down to 15s when I immediately tab to another app, thus putting the editor to the background.

What's more: if I put the editor into the background but constantly move the mouse over the editor window, the processing completes in the same time as if the editor were in the foreground all the time.

I assume this to be some Windows (11?) optimization to purposefully slow down apps in the background. I could not find a way to disable this for a particular app or system-wide for me as an end-user. Does such an option exist for end-users or a workaround?

Is there anything an app developer can do to prevent this behaviour?

Because I have observed that the same issue does not exist when running Unity editor on Ubuntu 22 in VMware - the tests always complete fast regardless of whether I put the editor in the background within the VM, and not even when I put the entire VM to the background. This makes me hopeful that there are ways to prevent this behaviour.

FYI: The whole issue has been documented as a bug report to Jetbrains and in the Unity forum. I'm hoping I don't have to wait for a fix of either app, I'd rather wish to adjust some system setting and fix this highly undesirable Windows behaviour for good.

I have already tried changing the following settings to no avail:

  • Unity Editor interaction Mode (Preferences => General) set to "No Throttling" and "8 ms" (120 Hz)
  • using Task Manager to set the Unity.exe process to "Realtime"
  • disabled "Hardware-Accelerated GPU Scheduling" (Settings: System>Display>Graphics>Default graphics settings)
  • via Advanced System Settings: Performance Options => Advanced I set "Adjust for best performance of: Background services"
  • turned off "Game Mode"
  • set power plan to "Best Performance"
  • wrote an autohotkey script that moves the mouse by 1px once every ms but this only speeds up execution by 50% (8s) and requires the cursor to be over the editor window
  • changed SystemResponsiveness to 64 (100%) (see below) and added NoLazyMode=1 (in the same registry key)
  • disabled Windows Defender realtime protection (see comment)
  • disabled powerthrottling of unity.exe via powercfg
  • manually adjusted Win32PrioritySeparation in registry

The last two tips were from this superuser post.

Temporary Workaround: This is an odd one but works reliably for me in Unity 2021.2 and newer. However it needs to be re-applied manually after every script compile / assembly reload.

  1. Open Preferences: General => Busy Progress Delay
  2. Click and drag the label to change the value (any value is fine as long as it is changed - IMPORTANT: it does not work by entering a value directly in the text field!)
  3. Run Unit Tests and put editor in background. Test continues to run fast.

I tried changing the corresponding EditorPrefs key "EditorBusyProgressDialogDelay" before running tests but this apparently does not trigger the code that makes the tests actually run faster. If anyone has any idea how to disassembly the editor code for the General Preferences that may help because then I could actually call that (possibly internal) method.

Additional note: setting Interaction Mode to No Throttling generally makes tests run 30% faster on my system!

music2myear
  • 40,472
  • 44
  • 86
  • 127
CodeSmile
  • 427
  • 2
  • 9
  • 17
  • If I understand right, this only happens in TestRunner? If the answer is positive, then your title needs to be more precise. – harrymc May 01 '23 at 11:07
  • You're right, I just assumed it's a general Windows thing. I've updated the title. – CodeSmile May 01 '23 at 12:35
  • I'm thinking this is something to do with the GPU or graphics driver and how it handles graphics work when a context isn't displayed. Is there a difference in performance when the app is minimised rather than just in the background, or when the app is fully visible but not focused? – Veltas May 02 '23 at 08:22
  • This is very anecdotal, but maybe try disabling Windows Defender/realtime protection? I remember some advice in the Unity docs that it can speed up headless CI WebGL builds by >2x, and I saw similar success when I did that myself (IIRC it went from 15m to 2m for me). Not sure if that will help the issue in this specific case though – Cobertos May 02 '23 at 09:08
  • @Veltas I have not observed a difference in Editor speed while it is in the background but it is hard to assess that anyway. However, some multiplayer devs have reported that running a build and editor in playmode and connecting both to the same session, then having the build window in focus will slow down the editor playmode instance. But I would assume that the "No Throttling" setting would fix that particular issue. – CodeSmile May 02 '23 at 15:34
  • 1
    @Cobertos I disabled realtime protection but TestRunner was just as slow with the editor in the background. Actually Rider automatically asks to exclude the project folder from Defender protection, which in case of Unity projects should apply to the entire Unity project. – CodeSmile May 02 '23 at 15:38
  • @CodeSmile Maybe Windows gives less priority to window messages in the background. I say this because you said moving the mouse cursor over the screen speeds it up, and that will pump the messages immediately. It's possible this behaviour occurs regardless of the background/priority settings you have because it's not about timeslicing but the messaging. Would be interesting if someone from MS or who otherwise knows could inform. – Veltas May 03 '23 at 07:56
  • Do not edit your question to add the answer. Read the Help section please. You are free, and ENCOURAGED, to answer your own question using the correct methods for this site. Editing your question to post the answer is not the correct method. – music2myear May 31 '23 at 02:55

3 Answers3

2

No idea if this will help you, but I have this registry edit stored somewhere, which supposedly modifies the reserved CPU for "background" or "low priority" processes. I think that you're supposed to enter the hexadecimal value here, so "64" for "100%".

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile]
"SystemResponsiveness"=dword:64
;end

This key contains a REG_DWORD value named SystemResponsiveness that determines the percentage of CPU resources that should be guaranteed to low-priority tasks. For example, if this value is 20, then 20% of CPU resources are reserved for low-priority tasks. Note that values that are not evenly divisible by 10 are rounded up to the nearest multiple of 10. A value of 0 is also treated as 10.

GChuf
  • 1,151
  • 9
  • 21
2

If I understand right, this only happens with Unity.

As you have tried every setting that Windows has for increasing the performance of background tasks, this is probably not a Windows problem. You have even in Task Manager set the priority to Realtime, which ensures that a process will have absolute CPU priority, but that was not enough for this one process.

My conclusion is that the problem is with the process itself, and this is Unity bug. I don't think that there is a Windows solution to the problem.

One might be able to write a program that will send Windows API messages to the process that will convince it that it's running in foreground mode while in the background, but I don't know of a product that does that.

harrymc
  • 455,459
  • 31
  • 526
  • 924
  • 1
    I've already reported it to Unity as bug. Since the first report on the forum was 4 years ago I was hoping there must be a known workaround. – CodeSmile May 01 '23 at 12:38
0

Pasting the solution OP wrote incorrectly as an edit to their question:

SOLUTION: The background test run slowdow described below no longer occurs in Unity 2023.1.0b14 (beta) and 2023.2.0a12 (alpha). I wrote a script that speeds up TestRunner by ~30% in general in my use case, and speeds up test runs from within Rider by a factor of 5 (but as of today only when using Unity 2023).

This is achieved by temporarily setting Editor Interaction Mode to No Throttling during a test run. Of course you can manually change this setting permanently - but keep in mind this is going to permanently and unnecessarily waste energy / drain the battery and increase heat & noise.

music2myear
  • 40,472
  • 44
  • 86
  • 127