Extremely slow editor in 2019.2.0a7

Unity Engine
21

Please submit a bug-report as described in this document:
https://unity3d.com/unity/qa/bug-reporting

It’s important that you report these issues together with a reproduction project if you want them to get fixed. If you don’t do it, it might be a long time until someone else reports them or until Unity Technologies find them.

After you submitted the bug-report, you receive a confirmation email with a bug-report Case number. Please post the Case number (number only, not the link) in this forum thread for Unity staff to pick up.

22

Our project can’t be tested without Unity first installing our application to have all the prelim data setup, so we can’t submit an effective bug report just via the Bug Report system.

However, I might make a new unity project where I can force the reproduction of these spikes without needing to send our software across. :slight_smile:

23

I believe that would be the recommended way to get a reproduce for Unity Technologies too. The easier it’s for them to reproduce an issue, the more likely it’s to get fixed.

24

I started seeing the OP’s issue on macOS Mojave (10.14.4) after upgrading from 2018.x to 2019.1. Perhaps related, I also started using Unity Hub to manage Installs rather than direct installations.

Ultimately the issue was alleviated by turning on vsync (using the button in the Game window’s menu bar). I don’t see the issue on my Windows 10 machine with vsync disabled.

Before I figured out the vsync solution, I was able to mitigate the issue by turning off Metal (using OpenGL instead) in the Player settings menu. Perhaps there is an issue with the way Unity’s Editor handles Metal without vsync.

I did not see this issue when using 2018.3 from a direct installation, though I can’t say for sure if I was using the same revision of Mojave at the time.

25

Samples page-3

Some tests on the newest post here

26

With gpu profiling turned on, the render thread usage and gpu usage is suddenly really high, which seems to be the correct data, compared to before. Weird.

Edit:
There seems to a lot really wrong. These gpu rates weren’t that high with same scene setups and tests before 2019.1, the drae call rates are sometimes off, the render usage rate isn’t right until using the gpu profiler, and Semaphore.waitforsignal causes higher cpu usage because the gpu usage is high, with a nearly linear increase… soo, always higher cpu usage, it serms like.

Edit 2:
It’s all running with way less problems and much faster in 2018.3 (14f1) (Edit: 2018.4 was problematic, too)

Edit 3:

Also, 2018.3 is not causing the TAA artifacts / frame smoothing, the editor is much faster (also, occlusion baking is faster and there are not the GI baking problems I had with 2019.1+ (Where baking took really long and sometimes GI wouldn’t be displayed).

Edit 4: By the way, the problems with 2019.1 + were present in builds too, not just the semaphore.waitforsignal thing.

Edit 5: Okay, Gfx.WaitForPresent is still there in 2018.3(14f1), causing high cpu usage, but still, everything’s running much faster and there are less editor problems.

Edit 6: I closed the profiler (GPU profiling was enabled, too) entirely, the fps rate is much higher in 2018.3(14.f1) now. And the render thread usage dropped from around 20ms to 5ms again. Similar to the time when I enabled gpu profiling in a newer unity version which showed that gpu usage wasn’t at around 7ms, but 50-60ms (Also in the stats tab in game view)

Edit 7: Also, when having gpu profiling enabled, it can be seen that volumetric fog takes around 30ms in newer unity versions, and just about 3ms in 2018.3

Edit 8: Disabling gpu profiling sets the render thread usage way down.
Closing the profiler entirely sets render thread usage down to about 3ms from around 18 MS in a testscene (Similar to disabling the gpu profiler), and cpu usage way down, too, giving me over 100 fps in that certain testscene, to around 60 with the profiler opened. There are many inaccuracies using the profiler and testing inside the editor at all

27

I ran into this issue when trying to edit a Probuilder/Polybrush mesh, during which the Editor becomes unusably slow with 2-10 seconds per frame, time spent in Semaphore.WaitForSignal inside of Gfx.ReadBackImage.

Switching the Graphics API for Mac to OpenGLCore is a workaround.

I have submitted a bug report.

2 Likes
28

I just ran into this also. In this cast I’m using WeatherMaker, and when a “Light” property (“get_Light()”) is accessed, it causes a 30.21ms delay waiting on Semaphore.WaitForSignal().

29

Could you please post the issue ID?

30

Could you please submit a bug report with your reproduction project attached?

31

Same here, scene with nothing but only one generated mesh (that represent grid) with simple shader
cause fps drop from 60 to 4 on Android (editor and standalone show ~1000fps) I tried vsync on/off, change different shaders,burst safety checks on\off,switch different graphics api, and nothig helps. In profiler i saw gfx.waitforpresentongfxthread takes ~700 ms on OpenGLES, and now i see Gfx.endasyncjobframe takes ~300ms on Vulkan

UPD For clearness, not only this mesh in the scene, but enabling this mesh cause issue, if i disable this object evrything goes back to normal 60 fps on android

1 Like
32

Having the same issue. What set it off for me was moving a couple variables (just storing some positions and rotation) from Start to OnEnable. The weird thing is I did this for two objects with virtually the exact same functions (don’t ask), and it worked perfectly when this change was made on the first object, but cropped up immediately when made on the second object. Literally no other changes were made between between the addition of these two lines, save for simply clicking the play button in the editor. Even stranger, the problem now persists in the same two lines of code on the first object that it originally worked fine on.

Pre-post edit: Upon further testing, the issue on one of the objects was resolved by removing the 2 lines in question, saving the script without them and running in the editor, and then adding the 2 lines back in. Unfortunately, removing the 2 lines and even the method entirely did not resolve the issue on the other object. It just doesn’t add up.

The issue has the appearance of randomness, so I’m honestly not sure if it’s easily replicable with a simplified project. I would at least attempt to replicate it in a simplified project and submit a report, but due to other setbacks that cropped up last week, I’m now 6 days behind and simply can’t afford to spend any more time on stuff like this, I have to move on. If for nothing else than my sanity.

If I do happen to catch up on the roadmap next week I’ll try to come back to this.

33

QA was able to reproduce this issue on one of their machines. The devs will look into it. You can check the status of the issue here: https://issuetracker.unity3d.com/product/unity/issues/guid/1154911/

2 Likes
34

Good news! Thank you :slight_smile:

35

Been ripping my hair out trying to figure out why such a simple game like the one I’m making is struggling to push frames on Android. Thank you for validating my woes. :smile:

36

Was there ever a fix to this? I’m getting this same issue on Unity 2019.1.0f2 windows 10

3 Likes
37

I was having the same issue while testing in 2019.2.0b5, showing up as both:

Gfx.WaitForPresent > Semaphore.WaitForSignal
+
PostLateUpdate.PlayerUpdateCanvases > UIEvents.WillRenderCanvases > UGUI.Rendering.UpdateBatches > Canvas.BuildBatch > Semaphore.WaitForSignal

But primarily the latter.

I successfully fixed it.

I did two things:

  • Rolled back to 2019.1. This was not downgrading; I manually updated my a pre-beta version to catch up. This did NOT fix it, which was terrifying. I’m still on 2019.1 now.

  • Then I upgraded my NVIDIA drivers, and that seems to have resolved the issue. I also upgraded all other drivers too but it’s probably the NVIDIA ones that fixed it. So, try upgrading your drivers maybe that will help.

1 Like
38

I been having the Semaphore.WaitForSignal issue in the profiler (hitting 80%+). This fixes both 2018 and 2019 versions for me on Mac. Simply docking shader graph, pro builder, and poly brush windows fixed it.

Shader graph if not docked would make my both my game and scene view unusable. Pro builder would crash unity if you zoom (f) on an object in a scene.

Also disabling metal editor in the project settings is a temporary fix.

39

I was having this issue and changing the game window resolution from 4k to 1080p seems to work (for now).

1 Like
40

Have the same problem in 2019.1.3f and 2019.1.8f