WebAssembly native dependency builds incrementalism is still slow

[SteveSandersonMS]

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:

• Use emcc --version, and comparing versions only if EMSDK_PATH was set, IOW, emsdk isn't being used from the workload
• Moved to a separate issue - [wasm] Add mono-aot-cross --print-runtime-icall-table to the cross compiler nuget #90366
• ConvertDllsToWebcil - do this only if necessary
• Emit compiling native files.. only if we will actually do anything
• Run _GenerateManagedToNative only if necessary. This takes ~1.6s on my machine.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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

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

Author:	SteveSandersonMS
Assignees:	-
Labels:	arch-wasm, untriaged
Milestone:	-

[marek-safar]

/cc @radical

[radical]

• The PInvokeTableGenerator, and the IcallTableGenerator are the only tasks that get re-run here, when you only change managed code. But they don't touch their output files, so other native bits won't run.
• I am going to narrow the cases where _CheckEmccIsExpectedVersion gets invoked, but we can do more for here, if needed
• target _WasmCompileNativeFiles runs embuilder to warm up the cache, but maybe we can do something here to avoid doing it more than once. Though cost on subsequent runs isn't high

There is one issue where you end up with the native table generators running every time:

1. first native build
   -> results in .dll having TD0 timestamp, and pinvoke-table.h having TP0 timestamp

2. change a .cs file
   -> results in .dll having TD1 timestamp
   -> PInvokeTableGenerator runs because .dll is newer, but pinvoke-table.h is not overwritten because the contents didn't change, so it still has TP0

3. rebuild with no changes
   -> .dll is still TD1
   -> PInvokeTableGenerator runs again because the .dll (TD1) is still newer than the table (TP0)

One solution would be to write the table file every time, so it gets the latest timestamp, but then that affects building the native files that depend on it, like pinvoke.c depends on pinvoke-table.h to build pinvoke.o. Re-working the tasks, and targets we could probably improve this too.

We plan to merge the pinvoke, and icall table generator tasks to reduce the cost a bit.

IOW, I can change some parts of this to improve some cases. But for others, it probably needs more work, and I'm not sure if that's worth it in the short term. Eg. it conflicts between build/publish, so it would make sense to wait for that to be resolved first.

If it seems worth the effort, then I can figure out some solutions for these.

TODO:

• Run emcc --version only when really needed. Check if there is better way to do this
• embuilder minimal - run only when really needed
• more work: figure out a better way to express dependencies, and track changes
• Check if we can add mono-aot-cross --print-runtime-icall-table to the nuget, and thus avoid invoking it

[lewing]

the table generators are a single task now, we should redo the timings.