-
-
Notifications
You must be signed in to change notification settings - Fork 15.1k
Perf: investigate manual inlining in layout.rs #99117
Copy link
Copy link
Closed
Labels
A-allocatorsArea: Custom and system allocatorsArea: Custom and system allocatorsI-slowIssue: Problems and improvements with respect to performance of generated code.Issue: Problems and improvements with respect to performance of generated code.T-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.
Description
Metadata
Metadata
Assignees
Labels
A-allocatorsArea: Custom and system allocatorsArea: Custom and system allocatorsI-slowIssue: Problems and improvements with respect to performance of generated code.Issue: Problems and improvements with respect to performance of generated code.T-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
Due to how many different times the layout code is instantiated, seemingly inconsequential changes can have noticeable impact on compile perf.
It may be beneficial to investigate some manual inlining (open coding) of code in the layout code (e.g. replacing
?and other option/result combinators withmatch/return) to reduce the amount of IR LLVM has to deal with.