Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linker performance problems #918

Open
vargaz opened this issue Jan 15, 2020 · 4 comments
Open

Linker performance problems #918

vargaz opened this issue Jan 15, 2020 · 4 comments

Comments

@vargaz
Copy link
Contributor

vargaz commented Jan 15, 2020

Linking a hello world with:
monolinker -a hello.exe -c link
Takes about 4.7 seconds with 8a82325. This is a problem since the linker is on a critical path of the build and its ran serially. This used to be about 1-2 seconds. Link time should be proportional to the size of the final app.

Notes:

  • Adding --disable-opt ipconstprop reduces the run time to 3.3 secs.
  • The TypeMapStep loads and processes the whole unlinked assembly.
  • Multiple passes are made over the IL, i.e. in MethodBodyScanner.
@jeromelaban
Copy link

jeromelaban commented Jan 8, 2021

Note that this specific issue is impacting .NET 6 based build significantly, and impacts other projects such as http://github.com/unoplatform/uno.

The default Uno configuration is to use the linker (so the projects are the smallest possible), but we're also hinting users that want to improve build performance to disable it to get a faster inner dev loop.

@jeromelaban
Copy link

I've done some profiling of the linker, here's what stands out:

image

And a large portion of the time is spent only resolving types and modules:

image

@MichalStrehovsky
Copy link
Member

Oh, interesting - we spend a surprising amount of time in the MethodBodyScanner. Last time I was looking at that, it seemed like we could delete the entire MethodBodyScanner without replacement, delete the tests that are testing stuff it keeps, and still have correct outputs (#1428). Do I read it right that it would be potentially a big speedup?

@jeromelaban
Copy link

In this particular profiling session, for a small application, the linking time is around 00:01:15 on an i9 machine. Optimizing this part would definitely make a difference.

marek-safar added a commit to marek-safar/linker that referenced this issue Apr 20, 2021
This change introduces a commonplace for resolving definition for types,
methods and fields. This is useful for following reasons

- Speeds up linker by 20% for default Blazor app (more for large apps)
- Any custom step can avoid building local mapping cache
- Custom steps could support `--skip-unresolved` linker option
- Consistent error handling for unresolved references

Most of the changes are just mechanical method replacement and
Link context passing.

Contributes to dotnet#918
Fixes dotnet#1953
marek-safar added a commit to marek-safar/linker that referenced this issue Apr 20, 2021
This change introduces a commonplace for resolving definition for types,
methods and fields. This is useful for following reasons

- Speeds up linker by 20% for default Blazor app (more for large apps)
- Any custom step can avoid building local mapping cache
- Custom steps could support `--skip-unresolved` linker option
- Consistent error handling for unresolved references

Most of the changes are just mechanical method replacement and
Link context passing.

Contributes to dotnet#918
Fixes dotnet#1953
marek-safar added a commit to marek-safar/linker that referenced this issue Apr 20, 2021
This change introduces a commonplace for resolving definition for types,
methods and fields. This is useful for following reasons

- Speeds up linker by 20% for default Blazor app (more for large apps)
- Any custom step can avoid building local mapping cache
- Custom steps could support `--skip-unresolved` linker option
- Consistent error handling for unresolved references

Most of the changes are just mechanical method replacement and
Link context passing.

Contributes to dotnet#918
Fixes dotnet#1953
marek-safar added a commit that referenced this issue Apr 22, 2021
* Unified handling of Resolve calls

This change introduces a commonplace for resolving definition for types,
methods and fields. This is useful for following reasons

- Speeds up linker by 20% for default Blazor app (more for large apps)
- Any custom step can avoid building local mapping cache
- Custom steps could support `--skip-unresolved` linker option
- Consistent error handling for unresolved references

Most of the changes are just mechanical method replacement and
Link context passing.

Contributes to #918
Fixes #1953

* Update src/linker/Linker/LinkContext.cs

Co-authored-by: Vitek Karas <[email protected]>

* PR feedback

* Simplify MethodReturnValue node construction

Co-authored-by: Vitek Karas <[email protected]>
agocke pushed a commit to dotnet/runtime that referenced this issue Nov 16, 2022
* Unified handling of Resolve calls

This change introduces a commonplace for resolving definition for types,
methods and fields. This is useful for following reasons

- Speeds up linker by 20% for default Blazor app (more for large apps)
- Any custom step can avoid building local mapping cache
- Custom steps could support `--skip-unresolved` linker option
- Consistent error handling for unresolved references

Most of the changes are just mechanical method replacement and
Link context passing.

Contributes to dotnet/linker#918
Fixes dotnet/linker#1953

* Update src/linker/Linker/LinkContext.cs

Co-authored-by: Vitek Karas <[email protected]>

* PR feedback

* Simplify MethodReturnValue node construction

Co-authored-by: Vitek Karas <[email protected]>

Commit migrated from dotnet/linker@012efef
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants