LiteNetLib
LiteNetLib copied to clipboard
Added .NET5+ Member Trimming Annotations
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 this increases complexity of library support to reduce size just by 25kb? I don't think this has much sense.
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.
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.
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.
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
:pray: