-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
Instantiate fewer copies of a closure inside a generic function #46477
Copy link
Copy link
Closed
Labels
C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.I-compiletimeIssue: Problems and improvements with respect to compile times.Issue: Problems and improvements with respect to compile times.P-mediumMedium priorityMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.WG-compiler-performanceWorking group: Compiler PerformanceWorking group: Compiler Performance
Metadata
Metadata
Assignees
Labels
C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.I-compiletimeIssue: Problems and improvements with respect to compile times.Issue: Problems and improvements with respect to compile times.P-mediumMedium priorityMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.WG-compiler-performanceWorking group: Compiler PerformanceWorking group: Compiler Performance
Type
Fields
Give feedbackNo fields configured for issues without a type.
In serde-rs/json#386 we observed that a disproportionately large amount of serde_json lines of LLVM IR and compile time are due to a tiny closure inside a generic function. In fact this closure contributes more LLVM IR than all but 5 significantly larger functions.
The generic function needs to be instantiated lots of times, but the closure does not capture anything that would be affected by the type parameter.
Simplified example:
This gives the expected 1 copy of
fand 2 copies ofg, but unexpectedly 2 copies ofg::{{closure}}in the IR.@Mark-Simulacrum