LiteNetLib icon indicating copy to clipboard operation
LiteNetLib copied to clipboard

Added .NET5+ Member Trimming Annotations

Open Sewer56 opened this issue 1 year ago • 3 comments

This PR adds annotations for .NET 5+ Assembly Member Trimming.

In a real application, I have observed the following size reduction:
95,744 -> 70,656 bytes. (-26.21%)

This is actually less than usually observed with trimming, though within expectation due to the library's internal design.

Sewer56 avatar Jul 05 '22 20:07 Sewer56

@Sewer56 this increases complexity of library support to reduce size just by 25kb? I don't think this has much sense.

RevenantX avatar Jul 06 '22 09:07 RevenantX

Yeah, it's a bit unfortunate, some greater savings are potentially possible with some minor changes; e.g. making some components like NatPunchModule optional; but at the moment, it's not something worth optimising for as the library itself is already small in the first place.

That said, even taking that into consideration, there are still some good valid reasons for adding trimming annotations to libraries outside of that.

  • Annotating LiteNetLib for trimming is necessary to make trimming libraries that extend LNL safe for trimming.
    • Specifically, trimmer warnings bubble up from the framework, up the dependency chain; so in order for libraries which extend/make use of LNL to be safely trimmable, LNL needs to be trimmable; otherwise consumers of LNL wouldn't get all necessary warnings to make their stuff safe to trim.
  • Trimming support is required to be able to safely use library with NativeAOT (formerly CoreRT).
  • It is really not much maintenance overhead at all.
    • In practice, 95% of the time you only really need to annotate new endpoints that use reflection. Other trimmer unfriendly usages are quite rare in my experience.
    • You rarely add new code that requires trim warnings in practice, as not everyday you write reflection related code.
    • The built-in Trim Analyzer is pretty good at detecting trim warnings without need to publish these days; so you'd see warnings immediately in the VS Warnings window.
    • Ensuring trimming is good is also somewhat possible to automate; for example I've been considering adding Trim Warnings as errors in my own projects so PRs and other code changes wouldn't pass CI/CD until warnings are resolved.

Sewer56 avatar Jul 06 '22 12:07 Sewer56

To add to the previously posted list of reasons, in a recent change all assemblies will be trimmed with linking by default when trimming is enabled in .NET 7.

Sewer56 avatar Aug 21 '22 04:08 Sewer56

Would be great to have this PR landed, to make NativeAOT experience more pleasant. And soon we will have WASI-SDK in .NET 8 where size would matter a bit more.

kant2002 avatar Jun 18 '23 03:06 kant2002

Hi @kant2002 @RevenantX @Sewer56 I'd suggest that the need is not based on the desire for size reduction, but more that there is a need to run native binaries (no runtime), and perhaps more performance related, and that the AoT process may trim code the linker does not determine is being called.

Whilst we can add "all" the namespaces/types into a rd.xml file, would it not be great to have the [RequiresUnreferencedCode], [DynamicallyAccessedMembers], [DynamicDependency] and [UnconditionalSuppressMessage] attributes in the code - as applicable?

Here are the latest docs with .Net 8 also around the corner...

https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/prepare-libraries-for-trimming?tabs=net6&pivots=dotnet-8-0

Simonl9l avatar Sep 15 '23 23:09 Simonl9l

:pray:

Sewer56 avatar Oct 09 '23 17:10 Sewer56