Consider disabling Ref.Emit in System.Linq.Expressions on WASM

[MichalStrehovsky]

I was surprised the default Blazor WASM template depends on Reflection.Emit. This is because of System.Linq.Expressions.

System.Linq.Expressions can be compiled in a way that removes the Ref.Emit dependency (use interpreter only) - to do this set the IsInterpreting property in System.Linq.Expressions.csproj to true.

Compiling without Ref.Emit support saves 112 kB uncompressed and 44 kB compressed on System.Linq.Expressions.dll alone. I expect there will be more savings possible in CoreLib (the Ref.Emit implementation).

#38438 fixes some bitrot in System.Linq.Expressions that is necessary to build this way.

Cc @marek-safar @eerhardt

Tagging subscribers to this area: @cston
Notify danmosemsft if you want to be subscribed.

[marek-safar]

I was surprised the default Blazor WASM template depends on Reflection.Emit. This is because of System.Linq.Expressions.

I'm sad every time I see System.Linq.Expressions in the default template of size sensitive workloads. It might be worth checking how to make that conditional in Blazor.

System.Linq.Expressions can be compiled in a way that removes the Ref.Emit dependency (use interpreter only) - to do this set the IsInterpreting property in System.Linq.Expressions.csproj to true.

I think it'd be better to have this instead of compile-time constant use feature-switch RuntimeFeature.IsDynamicCodeCompiled as this is not arch but codegen switch we could use elsewhere.

Compiling without Ref.Emit support saves 112 kB uncompressed and 44 kB compressed on System.Linq.Expressions.dll alone.

We actually switched from interpreter to SRE a few years ago for Mono profile due to performance improvements but it's possible that for NET Core libraries the situation will be different. However, we need to test if the behaviour is the same and where we stand on performance.

[MichalStrehovsky]

I'm sad every time I see System.Linq.Expressions in the default template of size sensitive workloads. It might be worth checking how to make that conditional in Blazor.

Seems to be coming from Microsoft.Extensions.DependencyInjection 😞

[benaadams]

I'm sad every time I see System.Linq.Expressions in the default template of size sensitive workloads. It might be worth checking how to make that conditional in Blazor.

Seems to be coming from Microsoft.Extensions.DependencyInjection 😞

Might need correct flags setting for WASM?

runtime/src/libraries/Microsoft.Extensions.DependencyInjection/src/Microsoft.Extensions.DependencyInjection.csproj

Lines 11 to 15 in ed78fad

	<PropertyGroup>
	<ILEmitBackend Condition="'$(TargetFramework)' != 'netstandard2.0'">True</ILEmitBackend>
	<DefineConstants Condition="'$(ILEmitBackend)' == 'True'">$(DefineConstants);IL_EMIT</DefineConstants>
	<DefineConstants Condition="$(TargetFramework.StartsWith('net4')) and '$(ILEmitBackendSaveAssemblies)' == 'True'">$(DefineConstants);SAVE_ASSEMBLIES</DefineConstants>
	</PropertyGroup>

[MichalStrehovsky]

Might need correct flags setting for WASM?

Ah, I meant - the reference to Linq.Expressions is coming from DependencyInjection.

The fact that DependencyInjection can also use Ref.Emit is new information to me, but makes perfect sense (if you want bad startup time and DI by itself is still not slow enough, might want to insure it's really bad by adding Ref.Emit to the mix).

[benaadams]

The fact that DependencyInjection can also use Ref.Emit is new information to me, but makes perfect sense (if you want bad startup time and DI by itself is still not slow enough, might want to insure it's really bad by adding Ref.Emit to the mix).

😂 I think @migueldeicaza would sympathize with this position

[eerhardt]

Seems to be coming from Microsoft.Extensions.DependencyInjection 😞

I've logged #38678 to make DependencyInjection more trimmable. Fixing that will remove Linq.Expressions in a default Blazor WASM template app. After that, the only usage of Ref.Emit left is #38693.