Reduce allocations in ProjectItemInstance.CommonConstructor by settin…

[nareshjo]

This pull request was generated by the VS Perf Rel AI Agent. Please review this AI-generated PR with extra care! For more information, visit our wiki. Please share feedback with TIP Insights

• Issue: The allocation hot path ends in Microsoft.Build.Execution.ProjectItemInstance.CommonConstructor. In CommonConstructor, inheritedItemDefinitions is built as new List<ProjectItemDefinitionInstance>(itemDefinitions) (capacity == itemDefinitions.Count) and then inheritedItemDefinitions.Add(itemDefinition) is called when the project-level item definition exists. This could lead to a list resize as seen in stack trace.
• Issue type: Specify an up-front capacity for collections if one is known
• Proposed fix: Pre-sizing the list to the final size (itemDefinitions.Count + 1) is a safe and localized minimal change in this method and directly targets the List.Add -> EnsureCapacity -> set_Capacity frames seen in the stack trace that lead to TypeAllocated!Microsoft.Build.Execution.ProjectItemDefinitionInstance[].

Best practices wiki
See related failure in PRISM
ADO work item

[Copilot]

Pull request overview

This PR optimizes memory allocation in ProjectItemInstance.CommonConstructor by pre-sizing a list to avoid potential resizing operations. The issue identified through PRISM telemetry showed that when building the inheritedItemDefinitions list, the original code would create a list with exact capacity matching the input collection size, then potentially trigger a resize when adding one more item.

Key changes:

• Pre-allocate list capacity with Count + 1 to accommodate the potential addition of a project-level item definition
• Use AddRange to populate the list instead of the collection constructor
• Expand the ternary operator into an explicit if-else structure for clarity