Loading Demo Scene when Editor configured for Android Build Slows Editor to a Crawl

[mrblasto]

The title pretty much sums up the symptoms. The editor runs smoothly if I just have a player with just a few weapons and a cut down scene. A fully loaded player seems to slow the editor down a little but the scene seems to run ok. A player and the demo scene is unusable unless the editor is configured in PC/MAC/Standalone.

Auto generation of lighting is off and I've tried with the lowest quality settings. Neither makes a difference, it is not the baking lights, but just to be sure, I'm baking the demo scene to see if that makes a difference. Since my company specializes in mobile games and apps, this is unacceptable behavior. I've got a late model macbook pro running Mojave with plenty of RAM and a solid state drive, so it isn't my machine. I'd sure like to know what's going on. So far I don't see that UCC is any better than UFPS. Sure it's got third person and some cool weapons, but at least you could run UFPS when the editor configured for any platform and performance was good on both Android and iOS devices.

I could A/B to isolate the offending assets or perhaps its editor code, but it so tedious on an unresponsive machine I'm hoping that someone has encountered this before and has a solution.

Some more observations -- CPU load when Unity has focus is only 5% but it takes 6GB of memory which seems awfully high.

 

[Justin]

Have you tried profiling? As you mentioned, in the demo scene the slowdown is generally caused by the lights. You'll either want to let it finish baking or disable the realtime lights.

 

[mrblasto]

Have you tried profiling? As you mentioned, in the demo scene the slowdown is generally caused by the lights. You'll either want to let it finish baking or disable the realtime lights.

Here's a screenshot of the profiler. It shows a spike during the Gfx.WaitForPresent call of 10 seconds to process a frame. And it's all in a script. Unfortunately it doesn't show which script. I'm assuming those are user scripts, not code inside a dll. Also, the spike occurs on mouse or keyboard input.

 

[Justin]

Based on that post it looks like it's the profiler itself:

https://forum.unity.com/threads/gfx-waitforpresent.211166/

 

[mrblasto]

Except that the slowdown occurs whether the profiler is on or off or whether the window is open or not. It happens in the demo scene, but not in a minimal scene, and only in the android and iOS platform build settings. And it happens when the game player is off; any kind of input triggers the slowdown. And it does not happen in UFPS version 2 regardless of platform. The call is the same as in the link you provided, but in my case the profiler indicates its in the scripts and that's a profile of the editor, not the running game, the game player is off.

 

[Justin]

indicates its in the scripts

Can you post a screenshot of that?

 

[mrblasto]

Except that the slowdown occurs whether the profiler is on or off or whether the window is open or not. It happens in the demo scene, but not in a minimal scene, and only in the android and iOS platform build settings. And it happens when the game player is off; any kind of input triggers the slowdown. And it does not happen in UFPS version 2 regardless of platform. The call is the same as in the link you provided, but in my case the profiler indicates its in the scripts and that's a profile of the editor, not the running game, the game player is off.

A screenshot of what? Of the slowdown without the profile? A profile of the minimum scene? The profile deductions are all from the posted screenshot.

I did remove all the lights from the demo scene and that seemed to solve the problem. But remember, the problem occurred in edit mode with both real time lighting and autobake and the profiler turned off. A key question is does the profiler script usage only include user scripts? If the answer is yes, then perhaps there's an editor script somewhere that's either in a tight loop or is waiting for an event that never happens.

 

[Justin]

A key question is does the profiler script usage only include user scripts? If the answer is yes, then perhaps there's an editor script somewhere that's either in a tight loop or is waiting for an event that never happens.

No, it includes everything. It sounds like it was the lights causing the slowdown if removing the lights fixes it. In general if you hit a performance problem it is best to profile it, and even though the profiler adds some overhead on its own at least you can get a relative sense of what scripts (or Unity processes) are causing the problem.

 

[mrblasto]

Thanks. I was wondering why you didn't include simpler scenes as you did in UFPS and mobile UFPS? The demo in UCC and sky city in UFPS are great looking levels, but the simpler scenes, especially the clean scene in UFPS were very useful. Is there anything equivalent for UCC?

 

[Justin]

There are two main reasons for that:

- More scenes makes it harder to maintain and ensure each scene is updated with the correct references/settings when something is changed with a version update. Having a scene scene makes my workflow a lot quicker and I know that everything is correct. I could use prefabs but until 2018.3 there wasn't nested prefabs which made working with prefabs more difficult for configuring different types of characters. Unfortunately I won't be able to set 2018.3 as the base version of the asset for awhile so I don't think that this aspect will change immediately.
- The Character/Item Managers should make setting up new characters easy so having a basic scene isn't as necessary

With that said I am still evaluating if this is the correct approach.. version 2 has only been on the store for about three months so it's still a very new asset.

 

[mrblasto]

Here are some notes on improving performance of demo in editor on mac in a mobile build configuration:

1. Use half res textures in Project/Quality settings -- quality is poor but workflow is quick. Quality can be set back to full res textures when creating a build for target platform. A variation of this is to find the offending texture(s) and reduce their size. This latter process is tedious and I have yet to find out why particular textures are problematic, e.g. isolating the problematic textures does not reproduce the problem.

2. Rollback Unity Editor to 2017.4.18.

3. Run Editor in Standalone build configuration and use Cloud Build for mobile platform builds.

4. Rollback Mac OS to High Sierra or earlier (haven't tried this yet but other Unity users report this solving editor performance problem).

5. Turn off Metal Editor support in mobile build player settings. This doesn't improve things as much as the first 3, for example, playing demo scene in editor is still clunky, but at least you can manipulate the editor.