I just came to realize: when using Burst, Jobs, Collections etc. for editor tools, do we have a way to ensure that this user’s settings regarding Leak Detection, Safety Checks etc. do not affect (ie slow down) the editor tool?
Is there a way to ensure an editor tool’s assembly:
is using its own (static) leak detection / safety check / burst compiler settings?
is built with the release configuration (optimized code)?
For the first point I personally would read out the current mode with this and then display a warning to the user about the possibly reduced performance (and maybe display a button to “fix” it). I would not change it for the user automatically as its often used for debugging and I would instantly remove your asset if it would interfere with that.
Do you know the difference between Safety Checks/On and Safety Checks/Force On?
Trying to circumvent Force On is a massive red flag and I wouldn’t want to be anywhere near that asset. The attribute I specified is for the use case where known good code can run at full speed but user code can run with safety on during normal usage.
I never thought about “force on”, thinking it would force it on even if something else told it to be off.
Burst’s OptimizeFor attribute is, as far as I know, overridable via AOT Project Settings.
Being able to alert the user to potential loss of performance due to these settings is actually the safest and most convenient route, I’ll just go for that. After all, it would help me even in development to switch modes at will as usual. And no, certainly won’t be changing settings automatically, that would be intrusive.
