Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: dotnet/linker
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: b4d7670
Choose a base ref
...
head repository: dotnet/linker
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: d8c44b8
Choose a head ref
  • 1 commit
  • 4 files changed
  • 1 contributor

Commits on Jan 22, 2021

  1. Constant propagation directly from MarkStep (#1771) 

    Call constant propagation and branch removal processing directly from `MarkStep`:
* Renames `RemoveUnreachableBlocksStep` to `UnreachableBlocksOptimizer` - it's not a step anymore
* Rename members to use the `_name` naming convention (which is also used by `MarkStep`)
* Removes the "go over all methods in all assemblies and process them" logic
* Some small changes to the `ProcessMethod` API to be more suitable for the `MarkStep`
* The class is now instantiated by `MarkStep` and only lives as long as `MarkStep` does
* `MarkStep.ProcessMethod` calls the optimizer's `ProcessMethod` before doing anything else on the method (this is because the optimizer can modify methods body, so mark step should only look at the modified version of the method)

Some interesting statistics (on console helloworld):
* Before this change the optimizer processed 73K methods (every method at least once - total number of methods is 72K). After the change the optimizer only processes 12K methods (so a huge reduction). This also means that the large dictionary maintained by the optimizer on all processed methods is now 20% of before this change.
* Max stack size increased to 62 - this is because of different order of processing methods. The 62 comes from `ThrowHelpers` which initializes lot of resource strings (each a separate call to a different method), so at one point all of these dependencies are on the stack. This is not a problem, just slightly higher memory usage. It would become problematic if the stack depth reached several 1000s which is VERY unlikely to happen.
* Number of rewritten methods is down to 20% (from 746 to 117) - all of those not rewritten are actually not used by the app
* As far as I can tell, it produces the exact same output.

Very rough perf measurement on Blazor template app:
* Before all the constant prop changes (SDK from early December 2020): 6.1 seconds (on average)
* After this change: 3.4 seconds (on average)
    @vitek-karas
    vitek-karas authored Jan 22, 2021
    Configuration menu
    Copy the full SHA
    d8c44b8 View commit details
    Browse the repository at this point in the history
Loading