Swift 针对自定义结构体实际会执行哪些拷贝消除优化？

Great question—this is exactly the kind of deep dive into Swift’s performance internals that separates casual devs from those who build really efficient apps. Let’s break this down clearly, since the hand-wavy "compiler optimizes it" claims don’t cut it, especially given your valid comparison to C#.

First, the straight answer: Yes, the Swift compiler (backed by LLVM) absolutely performs copy elimination for custom structs—and unlike C#’s theoretical-but-unimplemented optimizations, this is actually deployed and working in practice.

Trigger Conditions & Judgment Rules #

The compiler uses static analysis to decide when it can safely skip copying a struct. Here are the concrete rules you can rely on:

• Rule 1: Read-only parameter passing
  If a struct is passed to a function, and the function only reads its properties (no modifications whatsoever), the compiler will pass a direct reference to the original struct’s memory (usually on the stack) instead of copying it. No copy operation happens at all.
  Example:

  struct LargeCustomStruct {
      var id: Int
      var name: String
      var timestamp: Date
      // ... 9 more properties to hit your 12-property example
  }
  
  func printStructInfo(_ structInstance: LargeCustomStruct) {
      print("ID: \(structInstance.id), Name: \(structInstance.name)")
      // Only reads properties—no mutations
  }
  
  let myBigStruct = LargeCustomStruct(...)
  printStructInfo(myBigStruct) // No copy performed
  

• Rule 2: Local struct mutations with no external references
  If you create and modify a struct entirely within a local scope (like a function), and the compiler can prove no external code has access to that struct instance, it will modify the struct directly in-place on the stack—no copy is needed. This even applies if you pass the local struct to other functions that modify it, as long as those functions don’t leak references to it outside the local scope.
  Example:

  func modifyLocalBigStruct() {
      var localStruct = LargeCustomStruct(...)
      localStruct.name = "Updated Name"
      updateStructTimestamp(&localStruct) // Even with inout, no copy needed
  }
  
  func updateStructTimestamp(_ structInstance: inout LargeCustomStruct) {
      structInstance.timestamp = Date()
  }
  

• Rule 3: Return Value Optimization (RVO) for structs
  When a function creates and returns a struct, the compiler skips creating a temporary struct inside the function and copying it to the caller’s variable. Instead, it constructs the struct directly in the caller’s allocated memory space. This works for any size of custom struct, no exceptions.
  Example:

  func createLargeStruct() -> LargeCustomStruct {
      return LargeCustomStruct(id: 123, name: "Test", timestamp: Date(), ...)
  }
  
  let result = createLargeStruct() // No copy—struct is built directly in `result`'s memory
  

Key Exceptions (When Copies Will Happen) #

The compiler can’t eliminate copies if it can’t guarantee safety:

• If the struct is passed to a function that might modify it, and the compiler can’t verify the function’s behavior (e.g., a function from a closed-source framework, or a dynamically dispatched method).
• If the struct is captured by a closure that might escape the current scope (since the closure could modify it later, requiring a copy to preserve value semantics).
• If you manually trigger a copy by assigning the struct to a new variable and modifying one of them (though even here, some edge cases might get optimized).

Why Swift’s Implementation Is Different From C# #

The core difference lies in the compiler and runtime design: Swift uses LLVM, which has extremely sophisticated static analysis for value-type memory layout and usage. Combined with Swift’s strict value semantics rules, the compiler can reliably prove when a copy is unnecessary. C#’s CLR, by contrast, has a different optimization priority and runtime model that hasn’t prioritized widespread copy elimination for value types, leading to Microsoft’s 16-byte recommendation.

内容的提问来源于stack exchange，提问作者Orion Edwards