Why settle for slow editor extensions?

[mrtkhosravi]

Unity editor extensions tend to be slow due to the fact that it will run in debug mode. Often the editor extensions are sold at asset store and the user will need speed, not the ability to debug the extension. Even if the calculation is happening in a DLL, it’s still in debug mode and will suffer from being unoptimized and having debug info attached to the jitted code.

I mean we can build players in release mode but why can’t we enjoy the release mode in editor extension? Some extensions are very simple and don’t care about performance but some may need as much cpu power as possible.

So with the whole hot reloading and stuff is it technically not possible to have optimized code or unity doesn’t see the need to make it available?

[hippocoder]

critical ones could use a dll I guess.

[mrtkhosravi]

@hippocoder

critical ones could use a dll I guess.

It would still run unoptimized code. On my tests it takes nearly twice the time it takes on a optimized standalone code.

[mrtkhosravi]

Here is a comparison of unity extension and standalone build. The computation happens in a DLL that is compiled with Release configuration. Both the extension and standalone app call the DLL.

You see there is a huge difference between the two

[neginfinity]

@mrtkhosravi

Here is a comparison of unity extension and standalone build. The computation happens in a DLL that is compiled with Release configuration. Both the extension and standalone app call the DLL.

You see there is a huge difference between the two

Without seeing your code it is impossible to tell if you’re using valid way to measure performance.
Debug.Log is SLOW, by the way.

so if you do something like this (pseudocode):

      while(...){
          prevTime = curTime;
         doSomething()
         curTime = getTime();
         Debug.Log(string.Format("Operation took {0}", curTime - prevTime));
      }

You’ll get invalid results, because you’ll include Debug.Log() into measurement.

[mrtkhosravi]

@neginfinity

Without seeing your code it is impossible to tell if you’re using valid way to measure performance.

I’m using StopWatch:

            stopWatch = new Stopwatch();
            stopWatch.Start();
            for (int i = 0; i < 100; i++)
            {
                sketchGraph.Calculate(SketchImage, true, true, DebugOpts.BranchMin);
            }
            stopWatch.Stop();
            Debug.Log("100 PPA took" + stopWatch.Elapsed.TotalMilliseconds + " ms");

[mrtkhosravi]

Can we have an official statement about this matter from UT devs?

[Tautvydas-Zilys]

@mrtkhosravi

Here is a comparison of unity extension and standalone build. The computation happens in a DLL that is compiled with Release configuration. Both the extension and standalone app call the DLL.

You see there is a huge difference between the two

Is that a Windows Forms application? That probably means you’re using .NET to run your code, while Unity uses Mono. Try building Standalone player from unity and then compare performance. There theoretically shouldn’t be any differences if you don’t attach a debugger.

[mrtkhosravi]

@Tautvydas Zilys

Is that a Windows Forms application? That probably means you’re using .NET to run your code, while Unity uses Mono. Try building Standalone player from unity and then compare performance. There theoretically shouldn’t be any differences if you don’t attach a debugger.

In the windows forms project the target platform is unity 3.5 .net full base class libraries. I thought that is unity’s mono.

I’ve put the method into Update() and built a windows player without Development and script debugging. The output_log.txt shows the method takes around 1900 ms. The editor extension takes 2700 ms. So there is still difference even though both are using the same method call of the same DLL. I can’t think of any explanation for this gap.