[SC] Usando Instruments para encontrar cuellos de botella

Comprensión durante la lectura

¿Por qué es fundamental medir el rendimiento antes de optimizarlo?

Solo se puede mejorar el desempeño de algo si se conoce el punto de partida. Por esto, "medir" es indispensable para poder determinar si hubo una mejora.

¿Cuáles son los tres problemas de rendimiento más comunes que menciona el artículo?

• UI colgada: La UI deja de responder porque el hilo principal tiene mucho trabajo.
• Mala paralelización: Una sola Task tiene mucho trabajo, en lugar de repartirlo entre varias Tasks que corran en paralelo.
• Actor embudo: Las Tasks deben esperar a que un actor maneje cierto trabajo, resultando en puntos de suspensión y retrasos.

¿Qué diferencia hay entre ejecutar la app en modo debug vs. release al perfilar con Instruments?

En Debug, Xcode activa muchas ayudas para desarrollo que cambian el comportamiento y el rendimiento real de la app.

En Debug normalmente se tiene:

• Optimizaciones del compilador desactivadas (-Onone)
• Símbolos completos para debugging
• Checks adicionales del runtime
• Más validaciones de Swift/ARC
• Más overhead del debugger (LLDB)
• Variables conservadas para inspección
• Código inline un poco menos frecuente
• Menos eliminación de código muerto
• Logging adicional.

En Release se tiene:

• Optimizaciones agresivas (-O)
• Inlining
• Especialización de genéricos
• Eliminación de código muerto
• Menos metadata de debug
• Menos overhead del rutine

¿Por qué el código inicial bloquea el hilo principal aunque compila sin advertencias?

Pese a que el código inicial tenía un Task, esta heredaba el contexto del tipo de dato contenedor, que era @MainActor, y esta invocaba a BadGradientWallpaperGenerator que era un struct que por defecto estaba aislada en MainActor.

Esto implicaba que todo se ejecutaba de forma serial en el hilo principal.

¿Qué rol juega @MainActor en el problema de rendimiento de BadGradientsGeneratorViewModel?

El hilo principal está bloqueado haciendo un trabajo pesado.

¿Por qué introducir un actor para la generación de wallpapers no resolvió completamente el problema de paralelización?

Aunque introducir el actor era una forma para forzar la ejecución del código fuera del hilo principal (es decir, en otro dominio de aislamiento diferente de MainActor), eventualmente se convirtió en un embudo porque todas las Tasks eventualmente tenían que pasar por el actor, quien las serializaba.

¿Qué hace nonisolated y por qué fue necesario aplicarlo a BadGradientWallpaperGenerator?

nonisolated le dice al compilador que BadGradientWallpaperGenerator no debía estar aislado en MainActor. En otras palabras: se debía ejecutar en un hilo de segundo plano.

¿Cuál es la diferencia práctica entre usar un TaskGroup y lanzar múltiples Task individuales en este caso?

Considerar las siguientes dos aproximaciones. La primera usa TaskGroup y la segunda, múltiples Task individuales:

Task {
  await withTaskGroup { group in
    for index in 0..<numberOfWallpapersToGenerate {
      group.addTask(name: "Wallpaper \(index)") {
        let wallpaper = await self.wallpapersGenerator.generate()
        return wallpaper
      }
    }

    for await wallpaper in group {
      wallpapers.insert(wallpaper, at: 0)

      if self.wallpapers.count == self.numberOfWallpapersToGenerate {
        self.isGenerating = false
      }
    }
  }
}

Notar que en el caso anterior se usa un Task para iniciar la ejecución de un método asíncrono desde un contexto síncrono. Luego se tiene un TaskGroup que, en su interior, dispara la ejecución de varios await self.wallpapersGenerator.generate().

for index in 0..<numberOfWallpapersToGenerate {
  Task(name: "Wallpaper \(index)") {
    let wallpaper = await ConcurrentWallpaperGenerator.generate()

    self.wallpapers.insert(wallpaper, at: 0)

    if self.wallpapers.count == self.numberOfWallpapersToGenerate {
      self.isGenerating = false
    }
  }
}

En este segundo escenario, se disparan varios Tasks, que ejecutan el código asíncrono await ConcurrentWallpaperGenerator.generate().

Tener en cuenta que:

• Con TaskGroup se procesan los resultados en el orden que llegan (for await wallpaper in group), pero el scope del Task externo garantiza que todo el trabajo termine antes de salir del bloque. Con Tasks sueltos no hay garantía de orden, ni de que todos terminen.
• Con Tasks independientes, si el objeto que los lanzó se elimina antes de que terminen, pueden quedar "huérfanos" ejecutándose sin contexto válido. El TaskGroup es concurrencia estructurada: su tiempo de vida está acotado al bloque.
• Con TaskGroup la comprobación if self.wallpapers.count == self.numberOfWallpapersToGenerate es innecesaria porque el bloque for await termina naturalmente cuando todos los resultados fueron consumidos. Con Tasks sueltos esa es la única forma de saber cuándo terminaron todos, lo que es más frágil (condición de carrera si wallpapers no está protegido con un actor).
• self.wallpapers.insert(wallpaper, at: 0) en Tasks independientes puede generar una condición de carrera si self no es un actor. Con TaskGroup dentro de un solo Task, el acceso sigue siendo secuencial dentro del for await, lo que lo hace más seguro.

¿Por qué se eliminó el actor WallpapersGenerator en la versión final y qué lo reemplazó?

El actor WallpapersGenerator se convirtió en un embudo y todas las Tasks que ejecutaban de forma paralela, terminaban atascadas en el actor que ejecutaba un llamado a la vez.

La versión final se apoyó en el uso de @concurrent, que hace que un método nonisolated NO HEREDE el dominio de aislamiento del método invocador, sino que lo fuerza para ejecutarse en segundo plano. Esto significa que al llamar método marcado con @concurrent desde el ViewModel que estaba aislado en MainActor, el trabajo igual se podía ejecutar en segundo plano.

struct ConcurrentWallpaperGenerator {
  @concurrent
  static func generate() async -> Wallpaper {
    let generator = BadGradientWallpaperGenerator(
      width: 640,
      height: 360,
      controlPointCount: 2,
      nearestPointsToSample: 1
    )

    let image = generator.generate()
    return Wallpaper(image: image)
  }
}

---

Revisión y síntesis

¿En qué escenarios sería preferible mantener un actor en lugar de usar @concurrent?

¿Qué limitaciones tiene este enfoque de optimización si la app necesita cancelar todas las tareas en curso?

¿Por qué el artículo afirma que el código puede ser correcto en Swift 6 Strict Concurrency y aun así tener problemas graves de rendimiento?

---

Bibliografía

• Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.