Huge Editor overhead

Beginner Questions
#1

Hi there!

So I’m started to use the free version of this wonderful package a few weeks ago and there is something that bugs me. (Actually it mislead me thus the post)
Issue (i7 + 16Gig ram + win10 + unity 2017.4.2f2):

  • The Editor overhead is so huge that it lead me to believe that the package is useless at first :). Running the same application as a standalone (.exe, .apk) have no problems. Am I doing something wrong? Is there some toggle that I can switch so it would not destroy my poor editor :D.

My program does the following:

  • Spawn 10 to 30 new seeker each second (Instantiate)
  • Sends them toward a destination
  • Upon reaching the destination they are destructed (Destroy)
    I have 3 different scenario of doing this:
  • My own waypoint array + Vector3.moveTowards
  • A* Pathfinding Project: Seeker + AiPath+AiDestination setter
  • A* Pathfinding Project: Seeker for path + Vector3.moveTowards with my own script to move

The first scenario shows the usual editor overhead compared to standalone run: 20-30% cpu for editor overhead at around 2500 objects where the fps drops below 30 and I stop the test. 3500-3700 objects for standalone.
Third scenario : 80-90%+ cpu for editor overhead at around 250-300 objects where the fps drops below 30 and I stop the test. For standalone 3500 objects doesn’t even push the fps below 200

Any help how to make editor somewhat closer to reality ? :smiley:

#2

Hi

There are several things that could cause the slowdown. You can use the Unity profiler to check which one is more likely.

  • Make sure you disable ‘Show Graphs’ on the A* object, drawing graphs can be quite performance heavy for some graphs.
  • Disable gizmos on the Seeker object.
  • Create all objects as children of a single parent object and make sure that the parent is collapsed in the scene hierarchy. The Unity editor really doesn’t like having 3000 objects visible in the hierarchy at the same time, and it definitely does not want them all selected at the same time.

For newer Unity versions there can also be a difference between the runtime in the Editor and Standalone. If you have set the scripting backend to .Net 4 in the player settings then the Unity editor will use Mono, but a standalone player will use the .net backend. The .Net backend can for many workloads be 10 times faster than mono (mono is generating ridiculously bad code for many things).

#3

Hey!

Thanks for the answer!
Tried all of that (switching off the seeker gizmos helped some but the 1-2 order of magnitude performance difference remains between running the app in the editor vs running the standalone app in the target platform. (and my “scripting runtime version” is .NET 3.5, “scripting backend” is Mono.)

Profiling also doesn’t help much as there are no details for “EditorOverhead” in the profiler :).

#4

Hm… I don’t know really. Usually EditorOverhead in my experience comes from things like the hierarchy being too large or you using deep profiling, or something like that. It’s really hard to debug.