Custom EventSources in shared library seem to have unused code #54859
Assignees
Labels
Milestone
Comments
dotnet-issue-labeler
bot
added
the
untriaged
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
|
@LakshanF, FYI, the NetEventSource ones you're referring to are implemented as some shared methods in a partial class, and then each networking library includes that partial file and adds its own partial file that primarily just adds a unique guid / name. So it's not as simple as just removing unused code from that shared file, as different libs may use different subsets of the methods, and were relying on the linker to get rid of unused ones. |
|
@stephentoub, unfortunately the pending PR will make the trimmer not get rid of unused code in a special mode of trimming named 'library mode' that is used in building the libraries in the runtime. This is to handle cases like this library test that logs using the Below are some relevant details
|
|
So should we rather keep the special handling of EventSource until this is resolved? Are there reasons why we have to get rid of the special handling for .NET 6? Note that this is not just about the extra IL. It has also impact at runtime when tracing is enable that is increasingly more common. The event source will have to build manifests for the unused events now. |
There are two reasons
I suggested libraries trim mode implementation in the linker which would address that instead of marking everything. |
|
@LakshanF @vitek-karas do you plan on fixing this issue in .NET 6? |
|
We are talking to the network team to see if they can fix this (as in use only the source code they need instead of relying on the trimmer to remove unused code). Its possible that this might not be possible to do in 6.0 in which case, we can punt this issue |
|
I’m no EventSource tracing expert but I think the fix should be around not to use the same source code for all the NetEventSource (each net library have their own copy), remove methods that have the [NonEvent] attribute that are not used in the specific net library, and not to have nested types if generating the manifest is not needed. The above and library tests and consultation with tracing & trimmer teams should help with this |
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsThe There is a sizeable difference (around 70K or so of IL) of code that is kept after this trimmer change. A quick analysis of the difference shows that there are members in custom event sources that were not noticed earlier. For example, NetEventSource is used in multiple libraries where the additional members might not be needed (we shipped without this extra code prior to the trimmer change). Consider removing members from these custom
|
karelz
added
the
linkable-framework
|
Tagging subscribers to 'linkable-framework': @eerhardt, @vitek-karas, @LakshanF, @sbomer, @joperezr Issue DetailsThe There is a sizeable difference (around 70K or so of IL) of code that is kept after this trimmer change. A quick analysis of the difference shows that there are members in custom event sources that were not noticed earlier. For example, NetEventSource is used in multiple libraries where the additional members might not be needed (we shipped without this extra code prior to the trimmer change). Consider removing members from these custom
|
|
Below are the specific file size differences I can see when trimming shared FX assemblies in library mode (for example, for the first file, passing this line to the trimmer (with additional details): |
|
Additional details of unused source code of |
This was referenced Jul 21, 2021
|
@LakshanF is my understanding correct that the linker is currently unable to trim a substantial amount of code from If that's the case, could you please share how we can test the impact of such changes locally (linker commands, etc)? |
|
The linker runs automatically at the end of libraries build. You can do release build before and after the change and check the sizes of the affected assemblies. |
ghost
added
in-pr
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The
EventSourcetype has an attribute that the trimmer will interpret to keep all members of it as well as all its descendants. A pending trimmer checkin honors this for non-public customEventSourcesin library trim mode that affects the shared framework library build.There is a sizeable difference (around 70K or so of IL) of code that is kept after this trimmer change. A quick analysis of the difference shows that there are members in custom event sources that were not noticed earlier. For example, NetEventSource is used in multiple libraries where the additional members might not be needed (we shipped without this extra code prior to the trimmer change).
Consider removing members from these custom
EventSourcein the source code itself if they are not needed in the libraries or add tests if they are needed.The text was updated successfully, but these errors were encountered: