Description
The new native dependencies feature is great, but does come at a cost to build times even in cases where it seems like it shouldn't need to.
Once a Blazor WebAssembly application has a <NativeDependency>, each build takes an extra 3.5s even when nothing related to native dependencies has changed. In the case of a simple project, on my machine this means the build takes 3x as long (5.3s vs 1.7s without the native dependency).
Looking at the timeline in MSBuild structured log viewer, the expensive steps are:
_CheckEmccIsExpectedVersion - 0.6s_GeneratePInvokeTable - 1.05s_GenerateICallTable - 1.3s_WasmCompileNativeFiles - 0.65s
For a simple project, these completely dominate the overall build time.
Reproduction Steps
Create a Blazor WebAssembly application, e.g. using SDK 6.0.100-rtm.21508.19, and add any NativeDependency, e.g., a .c file called factorial.c containing:
int factorial(int n)
{
if (n == 0) return 1;
return n * factorial(n - 1);
}
... plus an itemgroup entry <NativeFileReference Include="factorial.c" />.
Build with dotnet build --no-restore --no-dependencies. Run this a couple of times to get the incremental state and warmed cache.
Compare again without the <NativeFileReference> (again, after a couple of builds to get the incremental state)
Expected behavior
When nothing has changed among the native file references, I would expect the build incrementalism to skip any nontrivial step. It does already skip calling emcc, but that's not the only expensive part. Even checking the emcc version is expensive.
I understand that you might still need to call _GeneratePInvokeTable since maybe the developer has added new DllImports. But once you see they haven't done so, it seems like it shouldn't be necessary to re-invoke anything else related to the native build.
Actual behavior
Re-runs build steps listed above.
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response
TODO:
Description
The new native dependencies feature is great, but does come at a cost to build times even in cases where it seems like it shouldn't need to.
Once a Blazor WebAssembly application has a
<NativeDependency>, each build takes an extra 3.5s even when nothing related to native dependencies has changed. In the case of a simple project, on my machine this means the build takes 3x as long (5.3s vs 1.7s without the native dependency).Looking at the timeline in MSBuild structured log viewer, the expensive steps are:
_CheckEmccIsExpectedVersion- 0.6s_GeneratePInvokeTable- 1.05s_GenerateICallTable- 1.3s_WasmCompileNativeFiles- 0.65sFor a simple project, these completely dominate the overall build time.
Reproduction Steps
Create a Blazor WebAssembly application, e.g. using SDK 6.0.100-rtm.21508.19, and add any
NativeDependency, e.g., a.cfile calledfactorial.ccontaining:... plus an itemgroup entry
<NativeFileReference Include="factorial.c" />.Build with
dotnet build --no-restore --no-dependencies. Run this a couple of times to get the incremental state and warmed cache.Compare again without the
<NativeFileReference>(again, after a couple of builds to get the incremental state)Expected behavior
When nothing has changed among the native file references, I would expect the build incrementalism to skip any nontrivial step. It does already skip calling
emcc, but that's not the only expensive part. Even checking theemccversion is expensive.I understand that you might still need to call
_GeneratePInvokeTablesince maybe the developer has added newDllImports. But once you see they haven't done so, it seems like it shouldn't be necessary to re-invoke anything else related to the native build.Actual behavior
Re-runs build steps listed above.
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response
TODO:
emcc --version, and comparing versions only ifEMSDK_PATHwas set, IOW, emsdk isn't being used from the workloadmono-aot-cross --print-runtime-icall-tableto the cross compiler nuget #90366ConvertDllsToWebcil- do this only if necessarycompiling native files..only if we will actually do anything_GenerateManagedToNativeonly if necessary. This takes ~1.6s on my machine.