We suspect we're noticing that Burst ***may ***not happen if you don't wait for the Editor to finish compiling its Burst process before building a standalone player.
#Burst compilation not happening in standalone 1.0-pre.44 builds?
spare dome
tepid inlet
no, that's unrelated; if something is not bursted, it's a separate problem
have you checked burst AOT settings in project settings and consulted https://forum.unity.com/threads/when-where-and-why-to-put-burstcompile-with-mild-under-the-hood-explanation.1344539/ ?
unrelatedly, if you're making a build, you should use .47, since it fixed a major issue in builds
spare dome
ok, could be that we are suffering whatever the major issue in builds was in .44 then
are you talking about the IL2CPP code stripping fix?
tepid inlet
Yep
spare dome
OK, well, I believe we are using Mono still. Does .47 make IL2CPP a valid build target? I think we were under the impression that IL2CPP builds simply did not work with ECS still.
tepid inlet
yep they work now
the problem was actually managed stripping
which you could turn on in mono also
spare dome
OK, thanks.
As far as the original problem I asked about. There are other people at my company investigating and they still suspect an editor bug is happening.
Current hypothesis is that the default background burst compilation has a race condition with domain reloads, which can cause it to sometimes not do the burst compile during the player build if a background task is already in-progress.
We'll likely submit a ticket through our support channel to Unity, but just wanted to update this thread with our findings so far.
tepid inlet
that's really very unlikely
burst compilation in the player is not connected to that in the editor at all
spare dome
Burst compilation is tied to the generic "build process" however, and it seems the Unity editor may be interrupting it during domain reloads.
I am not the one investigating though, just looking to see if there was maybe quick answers here.