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

Speed up type loading by storing type layout information in R2R images #45066

Open
11 tasks
Tracked by #44598
jkotas opened this issue Nov 22, 2020 · 7 comments
Open
11 tasks
Tracked by #44598

Speed up type loading by storing type layout information in R2R images #45066

jkotas opened this issue Nov 22, 2020 · 7 comments
Labels
area-ReadyToRun-coreclr design-discussion Ongoing discussion about design without consensus hard-problem
Milestone

Comments

@jkotas
Copy link
Member

jkotas commented Nov 22, 2020

The type loading involves non-trivial time-consuming algorithms such as field or vtable layout. We may be able to speed up the type loading by storing additional pre-computed information in the R2R images.

A possible design is to save just enough data to be able to build MethodTable very quickly, and teach the rest of the runtime to deal with MethodTables that do not have EEClass, MethodDescs or FieldDescs as they would be created on demand.

The data format should be resilient to versioning changes by default, with option to more efficiency via use of version bubbles.

Compact type layouts (CTL) was a similar idea used on Windows Phone. For inspiration, more details about CTL can be found in Patent # 10,656,926.

  • Estimate potential performance improvements
  • Field layout
    • Investigate feasibility of creating FieldDescs lazily
    • Design format of the field layout data
    • Generate the field layout data in crossgen2
    • Consume the field layout data at runtime
  • Vtable layout
    • Investigate feasibility of creating MethodDescs lazily
    • Design format of the vtable layout data
    • Generate the vtable layout data in crossgen2
    • Consume the vtable layout data at runtime
@Dotnet-GitSync-Bot
Copy link
Collaborator

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.

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Nov 22, 2020
@jkotas jkotas added area-ReadyToRun-coreclr design-discussion Ongoing discussion about design without consensus hard-problem labels Nov 22, 2020
@jkotas
Copy link
Member Author

jkotas commented Nov 22, 2020

cc @alpencolt

@mangod9 mangod9 removed the untriaged New issue has not been triaged by the area owner label Nov 23, 2020
@mangod9 mangod9 added this to the Future milestone Nov 23, 2020
@mangod9
Copy link
Member

mangod9 commented Nov 23, 2020

cc @dotnet/crossgen-contrib

@stephentoub
Copy link
Member

Potentially contributes to #44598

@lambdageek
Copy link
Member

Mono should do this too. On platforms where quick startup is critical (Android, wasm), using precomputed layouts could be beneficial. Additionally we could presumably avoid global loader lock contention.

@clamp03
Copy link
Member

clamp03 commented Feb 5, 2021

Quick startup is also critical on our Tizen products like wearable, TV, and so on.
I really look forward to this feature because R2R cannot meet our launching time comparing to FNV currently.
Thanks for your hard work. 👍

@wscho77
Copy link
Contributor

wscho77 commented Jun 8, 2022

Are there any progress about this feature?
After the latest .NET Runtime (FNV option removed) is applied for Tizen product, the startup time is increased.
We hope that this feature will be developed soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-ReadyToRun-coreclr design-discussion Ongoing discussion about design without consensus hard-problem
Projects
None yet
Development

No branches or pull requests

7 participants