Bug / Crash Burst not working at all

[whitexroft]

Have you checked that Burst is enabled for builds, as I suggested? 

...

The Oni/BurstColliderWorld object lifetime is managed by the solvers using lazy initialization: in the case you outline, since the world already exists in the scene it won't be created again on first use: the existing instance would be used.

I dont understand what do you mean by enabling burst for platform, you have seen the AOT settings. Im gonna check that Windows SDK and c++ build tools are installed, and try again

About the lazy initialization, what happens if there are a whole bunch of scenes, and all have sometimes OniWorldCollision, sometines BurstWorldCollision saved in them, sometimes both. The scenes are loaded additively

[josemendez]

I dont understand what do you mean by enabling burst for platform, you have seen the AOT settings. Im gonna check that Windows SDK and c++ build tools are installed, and try again

I saw your attached screenshot after writing my reply, so I edited it to include the suggestion about SSE4. If this doesn't get performance on par with the editor, then we should look elsewhere for differences that could explain the worse performance:
- Are you profiling a development build?
- Do you have different quality settings for the build?
- Are you building a 32 bit standalone instead of a 64 bit one?

About the lazy initialization, what happens if there are a whole bunch of scenes, and all have sometimes OniWorldCollision, sometines BurstWorldCollision saved in them, sometimes both.

This is totally fine. If some solvers in your scene use the Oni backend, others use the Burst backend, or have used either at some point in time, both instances might exist and/or be used. If you remove them, they will be re-created when needed.

[whitexroft]

I mean, yeah, im making development build, otherwise how would I profile it.
Ive verified that Windows SDK and build tools are installed
Quality settings are same, but then it doesnt matter, because it is Obi's substep itself that grows 2-3 times, not all the other things. And as you can see, architecture is 64 bit. 

I m not seeing any other options that i could tweak. Is there a way to validate that it is running Burst or fall backs to something else?

Since you cannot reproduce the freeze, how can I help you with that? I can reproduce it 100% cases.

[josemendez]

I mean, yeah, im making development build, otherwise how would I profile it.

You have deep profiling support enabled, so there's your answer: deep profiling has a huge negative impact on performance (and not just on Burst). Quote from the manual: https://docs.unity3d.com/Manual/ProfilerWindow.html

Deep Profiling is resource-intensive and uses a lot of memory. As a result, your application runs significantly slower while it is profiling. Deep Profiling is better suited for small games with simple scripting.

In my machine, building with/without deep profiling support makes a world of difference: 12 FPS with deep profiling support, 432 FPS without it. Also note that it is not necessary to actually attach the profiler to get a performance hit on a standalone build: the resulting code has profiler instrumentation compiled in, regardless of you retrieving the metrics or not. This is basically equivalent to a debug build in most compilers.

Since you cannot reproduce the freeze, how can I help you with that? I can reproduce it 100% cases.

Can you send a repro project to support(at)virtualmethodstudio.com with step by step instructions on how to reproduce it?

[whitexroft]

Thank you, that was it. I aplogize for being rude. Since I wasnt actually deep-profiling, I didnt expect it to behave like that.

So now I just need to figure out the freezes, and we can finally go with burst in the project. I ll try to make a repro sample for you  It's not that we prefer Burst over Oni library, its that we are building for the consoles, and there are no Oni libraries for these in the package.

[josemendez]

Thank you, that was it. I aplogize for being rude. Since I wasnt actually deep-profiling, I didnt expect it to behave like that.

So now I just need to figure out the freezes, and we can finally go with burst in the project. I ll try to make a repro sample for you  It's not that we prefer Burst over Oni library, its that we are building for the consoles, and there are no Oni libraries for these in the package.

No need to apologize!

You've probably noticed that when enabling deep profiling in-editor, Unity warns you that it will need to recompile all of your scripts. This is because deep profiling actually changes your code: it inserts extra profiling tools in every function, to be able to measure how much time each call takes. This not only makes your code much slower, it also consumes extra memory.

When you build a standalone version, you can't recompile things on-the-fly when attaching the profiler. Your code has already been compiled will all profiling scaffolding built-in, so you pay the price upfront.

If you can send a repro project I'd gladly take a look at it and investigate.

[josemendez]

Got to reproduce it! If you haven't prepared a repro project yet, no need to do it!

I'll see what the issue is and fix it, then get back to you with a patch. cheers,

[whitexroft]

Damn, I've just made the sample )
Tell me, if you d still need it

[josemendez]

Damn, I've just made the sample )
Tell me, if you d still need it

Found the bug and squashed it. The culprit was a weak_ptr in the Oni library, being disposed of in between a job schedule and its completion. This caused the job scheduler to wait forever for a job that would not get done. The fix will be included in the next update.

Let me know your email address and I'll send you a patched libOni.dll file. Replacing yours will fix the issue.

[whitexroft]

Found the bug and squashed it. The culprit was a weak_ptr in the Oni library, being disposed of in between a job schedule and its completion. This caused the job scheduler to wait forever for a job that would not get done. The fix will be included in the next update.

Let me know your email address and I'll send you a patched libOni.dll file. Replacing yours will fix the issue.

 
Oh, thats awesome! My email is victor[at]octato[dot]dk

So since I can now profile Burst thanks to you, could you tell how can I tackle this spike on scene load?
There seems to be plenty of Garbage collections in BeginStep, comparing to other normal frames
I can send my profile metrics to you if you want