How do I make the WasmEmitSymbolMap and/or WasmNativeStrip properties take effect?

Hammerite 0
Viewed 22

I want to be able to interpret an Edge performance profiler report for my Blazor WebAssembly app. To do this, I need to avoid the issue described in this question whereby all functions are renamed to names like "wasm-function[12345]". This answer aims to explain a means of doing this by setting the properties WasmEmitSymbolMap and/or WasmNativeStrip. However, it does not provide sufficient detail on how to get these properties to actually take effect. For me, they do not make any difference. The Edge performance profiler continues to name the functions according to the "wasm-function[12345]" pattern no matter what I try, and I cannot find the file "dotnet.js.symbols" - that supposedly ought to be created somewhere, since I specified WasmEmitSymbolMap - at all.

What I have tried

  1. I tried adding these lines within a PropertyGroup in the "client" project's csproj file:

    <WasmEmitSymbolMap>true</WasmEmitSymbolMap>

    <WasmNativeStrip>false</WasmNativeStrip>

  2. I tried adding those same lines within a PropertyGroup in the "server" project's csproj file, too, because the answer doesn't say which file they belong in.

  3. Because the answer warns that one of the two properties "can only be used in AOT compiled mode", I added the following line alongside the aforementioned ones in both csproj files:

    <RunAOTCompilation>true</RunAOTCompilation>

  4. I also tried adding the following line in both files:

    <RunAOTCompilationAfterBuild>true</RunAOTCompilationAfterBuild>

  5. At various times I tried force-refreshing (shift+F5) the page in my application, just in case something was out of date.

None of the steps 1, 2, 3 or 5 made a difference. As to step 4, I do not know whether this change would have fixed the problem or not, because it made the build take such a long time that I eventually gave up and cancelled it.

profiling blazor c#
1 Answers

The answer is I should have had more patience with RunAOTCompilationAfterBuild. It does do the job. Weirdly the second time I tried it, it didn't take as long and didn't appear to go through all the same steps as it had done the first time, so some stuff must have been cached or something. This is despite the fact I had cleaned the solution in the meantime.

So the answer is: put all this stuff in your csproj (the Client project csproj, I think, but it doesn't matter if it's in both):

<PropertyGroup>
    ...
    <RunAOTCompilation>true</RunAOTCompilation>
    <RunAOTCompilationAfterBuild>true</RunAOTCompilationAfterBuild>
    <WasmEmitSymbolMap>true</WasmEmitSymbolMap>
    <WasmNativeStrip>false</WasmNativeStrip>
    ...
</PropertyGroup>

and be aware that it will take a really long time to compile. like 10-15 minutes or maybe more, and for a lot of that time it will be sitting there not printing any output - it just sits there for several minutes with a message that mentions something called "emscripten".

Because it takes such a long time to compile, you won't want to do this routinely for your debug builds. Only when you specifically want to investigate a performance problem.

Additional relevant discussion here: https://github.com/dotnet/aspnetcore/issues/26850

Hammerite0
Related