[Blazor] "Tree Shaking" not workng as expected

[daniel-p-tech]

Hi,

I'm not sure if this is a bug or simply a typical output of the "tree shaking" algorithm when Blazor app is deployed into production.

I created a very small project that uses DevExpress Blazor components library. The project only contains one page that instantiates two lightweight DevExpress components. The entire library has over two dozens of components including some heavyweights like scheduler and grid.

When I compile the test project in the development environment, the size of the core DLL of the 3rd party library is 2,613,528 bytes. After publishing the project in the release mode, the size of the same file is 2,590,720 bytes - that's a reduction of less than 1%!

Before contacting DevExpress, I'd like to hear your explanation why there is virtually no reduction in size. My understanding was that the linker will strip off any code that is not used by my application. Clearly that should be closer to something like 50-80% depending on how much shared code is needed to instantiate two of their simplest components. Maybe I am doing something incorrectly?

Thank you!

[pranavkm]

My understanding was that the linker will strip off any code that is not used by my application

By default Blazor (and all of .NET Core) does not trim application code, it only trims the framework. There are patterns of code that are problematic with trimming. The runtime libraries have been updated and tested to make sure they play well with trimming, arbitrary libraries or user code might not be.

That said, you could configure the SDK to trim additional assemblies: https://docs.microsoft.com/en-us/dotnet/core/deploying/trimming-options#trimmed-assemblies

[daniel-p-tech]

I'm assuming this is mostly due to potential use of reflection? Does it mean that if the 3rd party vendor did not design the library to work properly with trimming, it will also preclude the AOT compilation from working properly?

Thanks.

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!