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
Tasktiene mucho trabajo, en lugar de repartirlo entre variasTasks que corran en paralelo. -
Actor embudo: Las
Tasks deben esperar a que unactormaneje 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
TaskGroupse procesan los resultados en el orden que llegan (for await wallpaper in group), pero el scope delTaskexterno garantiza que todo el trabajo termine antes de salir del bloque. ConTasks 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. ElTaskGroupes concurrencia estructurada: su tiempo de vida está acotado al bloque. - Con
TaskGroupla comprobaciónif self.wallpapers.count == self.numberOfWallpapersToGeneratees innecesaria porque el bloquefor awaittermina naturalmente cuando todos los resultados fueron consumidos. ConTasks sueltos esa es la única forma de saber cuándo terminaron todos, lo que es más frágil (condición de carrera siwallpapersno está protegido con unactor). -
self.wallpapers.insert(wallpaper, at: 0)enTasksindependientes puede generar una condición de carrera siselfno es unactor. ConTaskGroupdentro de un soloTask, el acceso sigue siendo secuencial dentro delfor 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)
}
}