Estoy tratando de exprimir hasta el último bit de rendimiento de mi aplicación. Intento usar Structs sobre clases siempre que sea posible (sin compartir estado, envío directo por defecto, etc., etc.). Pero mis controladores de vista y objetos UIView obviamente siguen siendo clases. Quiero forzar el envío directo en cada uno de mis métodos y miembros de datos, por razones de rendimiento.
¿Necesito marcar cada var , let y func en mi clase como final , o es suficiente marcar la clase de alojamiento como final, para que todo lo que está debajo aproveche el envío directo del método ?
En otras palabras: es muy tedioso pegar final en todas partes, antes de cada método y variable. Así que espero que solo ponerlo en la clase tenga el mismo efecto de forzar el envío directo a todos los miembros de la clase. Pero no sé cómo probarlo o verificarlo.
Para aquellos que se preguntan de qué estoy hablando, consulten este artículo: "Method Dispatch in Swift". Las estructuras y las extensiones de protocolo le brindan el envío de métodos estáticos de forma predeterminada (el rendimiento más rápido), pero las clases no. Los métodos estáticos en las clases sí, pero quiero forzar el envío estático en todos los métodos de instancia y miembros de datos.
https://www.raizlabs.com/dev/2016/12/swift-method-dispatch/
La documentación de Swift Language Runtime menciona el efecto sobre la capacidad de crear subclases, pero no describe lo que sucede con el comportamiento de envío de los miembros secundarios y las funciones de las clases que están marcadas como "finales". Sería bueno si todo lo que hay debajo obtuviera Despacho de método estático sin tener que marcar todo como final individualmente.
final
Aplique este modificador a una clase oa una propiedad, método o miembro de subíndice de una clase. Se aplica a una clase para indicar que la clase no se puede subclasificar. Se aplica a una propiedad, método o subíndice de una clase para indicar que un miembro de la clase no se puede anular en ninguna subclase. Para ver un ejemplo de cómo usar el atributo final, consulte Prevención de anulaciones.
Sí, solo marque el tipo como final y sus propiedades y métodos también son final . Pero si se trata de código UIKit (anulaciones de métodos, métodos delegados de UIKit, etc.), siempre se distribuirá de forma dinámica. En realidad, es solo material para su propio código computacionalmente intensivo, e incluso entonces existe la duda de si ese es el problema crítico o si hay otros problemas (por ejemplo, búsquedas en matrices en lugar de diccionarios, paralelización de rutinas complejas, uso de Accelerate o Metal de ciertas tareas, activando compilaciones de versión optimizadas, etc.).
Pero si está convirtiendo a envío estático en código que no se llama con mucha frecuencia, la diferencia puede ser modesta/no observable.
Deberíamos olvidarnos de las pequeñas eficiencias, digamos alrededor del 97% del tiempo: la optimización prematura es la raíz de todos los males. Sin embargo, no debemos dejar pasar nuestras oportunidades en ese crítico 3%.
Tengo curiosidad por saber si realmente has hecho suficientes análisis para confirmar que estás en ese 3 %. Si es así, me disculpo por señalar lo obvio; es solo que no vi nada arriba que indique cómo determinó que el envío estático iba a marcar una diferencia real. Si tiene un problema de rendimiento, es poco probable que pasar y hacer que todo sea final sea la bala de plata para resolver el problema.
Lo remitiría a los videos de la WWDC que describen metodologías para identificar y resolver problemas prácticos de rendimiento: