El coste: peso, arranque, latencia y los objetivos donde no existe

La reflexión se paga cuatro veces y casi siempre se contabiliza una sola. Se paga en bytes, porque la biblioteca que la implementa lleva dentro un analizador de metadatos completo y no es pequeña. Se paga en arranque, porque antes de responder la primera pregunta sobre una clase hay que decodificar la descripción binaria que el compilador dejó grabada. Se paga en cada invocación, porque una llamada que el compilador habría resuelto a una instrucción se convierte en una búsqueda, una comprobación de accesibilidad, un empaquetado de argumentos y una desreferencia indirecta. Y se paga, la cuarta vez, en libertad de despliegue: un programa que se consulta a sí mismo por nombre no puede ser podado por un optimizador que no sepa qué nombres se consultarán, no puede ser ofuscado sin reglas de conservación y no puede compilarse hacia objetivos donde el modelo dinámico de clases sencillamente no existe. Este nivel pone cifras y mecanismos a esas cuatro facturas, porque la decisión de usar reflexión solo es defendible cuando se conocen las cuatro.

El peso en el artefacto

La biblioteca de reflexión de Kotlin ronda los tres megabytes en su forma sin comprimir y aporta varias decenas de miles de métodos. En un servicio de servidor eso es irrelevante; en una aplicación móvil es una de las dependencias más caras que se pueden añadir por accidente, y se añade por accidente con frecuencia, porque basta con que una biblioteca transitiva la declare para que entre en el gráfico.

El problema mayor no es el tamaño bruto sino su interacción con el optimizador. Un reductor de código funciona demostrando que ciertas clases y ciertos miembros no son alcanzables desde ningún punto de entrada. La reflexión rompe esa demostración de raíz: si en algún lugar del programa hay una búsqueda por nombre, el optimizador no puede saber qué nombres se buscarán y debe elegir entre conservar de más o romper el programa. La salida práctica son las reglas de conservación, que hay que escribir a mano, que nadie actualiza cuando el modelo cambia y que en la práctica acaban conservando jerarquías enteras.

Conviene ver el tamaño de la renuncia con un ejemplo concreto. Para que una clase siga siendo inspeccionable tras la reducción hay que conservar la clase, sus miembros y, en Kotlin, además la anotación de metadatos sin la cual la biblioteca no sabe interpretarla. La regla resultante no protege un método: protege un subárbol.

// Reglas de conservacion tipicas, expresadas como comentario para leerlas aqui:
//   keep class com.ejemplo.modelo.**  con todos sus miembros
//   keepattributes RuntimeVisibleAnnotations
//   keep class kotlin.Metadata        con todos sus miembros

Cada línea de ese fichero es una porción del programa que el optimizador deja de tocar y que el ofuscador deja de renombrar. Multiplicado por las bibliotecas que también reflexionan, el efecto acumulado suele ser mayor que el peso de la propia biblioteca de reflexión, y es mucho más difícil de medir porque no aparece como una dependencia sino como una ausencia de reducción.

El arranque: decodificar antes de responder

El coste de arranque no viene de cargar clases sino de interpretar el metadato. El compilador de Kotlin graba en cada clase una anotación con una estructura binaria que describe lo que el formato de la plataforma no sabe representar: nulabilidad, propiedades frente a campos, valores por defecto, receptores de extensión, variancia, alias y clases selladas. La primera vez que se pregunta por una clase, la biblioteca localiza esa anotación, la decodifica, construye el modelo y lo cachea. Las preguntas siguientes sobre la misma clase son mucho más baratas; las primeras sobre cada clase nueva vuelven a pagar el precio.

Ese patrón tiene una consecuencia práctica que decide arquitecturas enteras: la penalización es proporcional al número de tipos distintos inspeccionados, no al número de operaciones. Un servicio de larga vida que inspecciona doscientos tipos en el arranque amortiza el coste en el primer minuto y no vuelve a pensarlo. Una aplicación de cliente que arranca, hace su trabajo y muere paga la factura completa en el tramo de tiempo que el usuario percibe, y la paga cada vez.

De ahí que la única mitigación realmente eficaz sea diferir: no inspeccionar en la construcción del componente sino en el primer uso, y cachear el resultado con una inicialización perezosa. La técnica no reduce el coste total, lo reparte, y evita pagar por los tipos que esa ejecución concreta no llegará a usar.

class Descriptor(private val k: KClass<*>) {
    // No se decodifica nada hasta la primera lectura real
    val campos: List<KProperty1<Any, *>> by lazy {
        @Suppress("UNCHECKED_CAST")
        k.memberProperties.toList() as List<KProperty1<Any, *>>
    }
}

private val cache = ConcurrentHashMap<KClass<*>, Descriptor>()
fun descriptorDe(k: KClass<*>): Descriptor = cache.getOrPut(k) { Descriptor(k) }

Nótese que la caché es imprescindible y que su clave es la propia referencia de clase, que pertenece al subconjunto ligero. Sin ella, cada consulta reconstruye el modelo y el coste deja de ser de arranque para convertirse en coste permanente.

flowchart TD
A[Primera consulta sobre un tipo] --> B[Localizar la anotacion de metadatos]
B --> C[Decodificar la estructura binaria]
C --> D[Construir el modelo y cachearlo]
D --> E[Responder]
F[Consultas siguientes sobre el mismo tipo] --> D
G[Proceso de vida corta] --> H[Paga la decodificacion completa en cada arranque]

La llamada reflexiva frente a la directa

Una invocación normal se resuelve en compilación: el destino es conocido, los argumentos van por el mecanismo de paso habitual y el optimizador puede incorporarla en línea, especializarla o eliminarla. Una invocación reflexiva no puede hacer nada de eso. Hay que localizar el miembro, comprobar la accesibilidad, empaquetar los argumentos en un arreglo, envolver los valores primitivos en objetos, desempaquetar el retorno y propagar los errores a través de una capa de excepciones envolventes. El resultado, medido con cuidado, sitúa la llamada reflexiva entre uno y dos órdenes de magnitud por encima de la directa, y la variante por mapa de parámetros bastante peor todavía, porque además construye estructuras intermedias en cada llamada.

class Punto(val x: Int, val y: Int) {
    fun distanciaAlOrigen(): Double = kotlin.math.hypot(x.toDouble(), y.toDouble())
}

val p = Punto(3, 4)

// Directa: el destino se conoce en compilacion
val a = p.distanciaAlOrigen()

// Reflexiva: busqueda, comprobacion, empaquetado, envoltura
val m = Punto::class.memberFunctions.first { it.name == "distanciaAlOrigen" }
val b = m.call(p)

Hay dos matices que evitan conclusiones simplistas. El primero es que buena parte del coste se puede amortizar: resolver el miembro una vez y guardar la referencia elimina la búsqueda, que suele ser la fracción dominante, y deja solo el sobrecoste de invocación. El segundo es que la comparación importa cuando la llamada está en un camino caliente; si la reflexión ocurre una vez por petición y la petición hace entrada y salida de red, la diferencia desaparece bajo el ruido. La conclusión correcta no es que la reflexión sea lenta, sino que su coste es fijo y no mejora, mientras que el de la alternativa generada tiende a cero.

Merece la pena desglosar dónde se va exactamente el tiempo, porque cada partida se ataca de forma distinta. La búsqueda del miembro por nombre recorre una colección construida al decodificar el metadato y solo se paga una vez si se cachea. La comprobación de accesibilidad ocurre en cada invocación salvo que se desactive explícitamente. El empaquetado de argumentos asigna un arreglo por llamada y envuelve cada valor primitivo en un objeto, con lo que introduce presión sobre el recolector allí donde la versión directa no asignaba nada. Y la indirección impide al compilador de la máquina virtual incorporar la llamada en línea, que es la optimización de la que dependen casi todas las demás.

class Invocador(k: KClass<*>, nombre: String) {
    // Resuelto una sola vez en la construccion
    private val m = k.memberFunctions.first { it.name == nombre }
        .also { it.isAccessible = true }

    fun invocar(receptor: Any): Any? = m.call(receptor)
}

Ese pequeño envoltorio suele reducir el sobrecoste en un factor considerable y no cambia nada del diseño. Es lo mínimo exigible a cualquier código de producción que reflexione, y su ausencia es un indicador bastante fiable de que la decisión de reflexionar no llegó a evaluarse.

Los objetivos donde simplemente no existe

En Kotlin Native y en el objetivo de Wasm la reflexión completa no está disponible, y es importante entender que no se trata de una laguna pendiente de rellenar. Ambos compiladores son de programa completo: analizan todo el código alcanzable y eliminan lo demás, y esa eliminación es precisamente lo que permite que un binario nativo o un módulo de Wasm tengan un tamaño razonable. Un mecanismo que resuelve nombres en ejecución es incompatible con esa estrategia, porque obligaría a conservar la totalidad del programa junto con una descripción de sí mismo. Además, ninguno de los dos objetivos tiene un cargador de clases dinámico ni un formato de clases inspeccionable en ejecución: no hay nada análogo a la anotación de metadatos que la biblioteca sabe leer.

Lo que sí existe en esos objetivos es el subconjunto ligero: la referencia de clase como identidad, el nombre simple, la comprobación de pertenencia, las referencias a función y a propiedad con su nombre y su invocación directa. En el objetivo nativo hay además un mecanismo específico que permite asociar un objeto a una clave de anotación y recuperarlo en ejecución, pensado exactamente para cubrir el caso de las factorías registradas sin necesidad de búsqueda por nombre. Es una pista muy clara sobre la dirección que ha tomado el diseño: en lugar de reproducir la reflexión, se ofrece un mecanismo declarativo que resuelve el mismo problema en compilación.

// Disponible en todos los objetivos: identidad, nombre y pertenencia
fun describir(v: Any): String = v::class.simpleName ?: "anonimo"

// No disponible fuera de la maquina virtual de Java: enumerar el modelo
// fun campos(v: Any) = v::class.memberProperties

La consecuencia de diseño es directa y afecta a cualquier módulo compartido entre plataformas. Si el código común reflexiona, deja de ser común: hay que duplicarlo con una implementación esperada y varias reales, y la real de los objetivos sin reflexión tendrá que resolver el problema de otra manera, casi siempre generando o registrando. Cuando eso ocurre, la pregunta obvia es por qué no usar desde el principio la solución que funciona en todas partes, y esa pregunta es la que abre el nivel siguiente.