Llega el momento en que tu informe de Power BI está bonito, el modelo está limpio, y aun así una medida específica tarda una eternidad en calcular. Culpar a la herramienta es fácil, pero casi siempre injusto: DAX es un lenguaje extraordinariamente rápido cuando se escribe con conciencia de cómo funciona por dentro. Optimizar medidas no es magia negra reservada a expertos — es conocer media docena de principios y aplicarlos con disciplina. Vamos a ellos.
Los dos motores detrás de cada medida
Para optimizar DAX, primero hay que entender que cada medida la resuelven dos motores. El Storage Engine es rápido, comprimido, trabaja sobre columnas enteras de una vez y puede usar varios núcleos del procesador en paralelo. El Formula Engine es más lento, trabaja fila a fila y usa un solo núcleo. La regla de oro del rendimiento es simple: hacer el máximo de trabajo en el Storage Engine y el mínimo en el Formula Engine. Casi todas las técnicas que siguen son variaciones de este principio.
Técnica 1: usar variables para no repetir cálculos
Una de las mejoras más fáciles y más ignoradas es guardar resultados intermedios en variables con VAR. Si una medida calcula la misma expresión tres veces, está haciendo el triple del trabajo. Al guardarla en una variable y reutilizarla, el cálculo ocurre una sola vez. Además de la velocidad, las variables hacen la medida legible y más fácil de depurar — un raro caso en que lo más rápido es también lo más limpio.
Técnica 2: filtrar columnas, no tablas enteras
Un error muy común es usar FILTER sobre una tabla grande entera cuando bastaba una condición sobre una columna. Escribir CALCULATE( [Ventas], FILTER( Tabla, Tabla[Año] = 2026 ) ) obliga al motor a recorrer la tabla entera fila a fila; escribir CALCULATE( [Ventas], Tabla[Año] = 2026 ) deja que el Storage Engine se encargue de forma mucho más eficiente. Siempre que sea posible, aplica el filtro directamente a la columna y reserva el FILTER explícito solo para condiciones que realmente lo exijan.
Técnica 3: cuidado con los iteradores sobre tablas enormes
Las funciones de la familia X — SUMX, AVERAGEX y compañía — son poderosas pero recorren la tabla fila a fila, territorio del Formula Engine. Sobre una dimensión pequeña, no hay problema. Sobre una tabla de hechos con millones de filas, un iterador mal pensado puede ser la causa de toda la lentitud. Muchas veces, es posible reformular el cálculo para que el trabajo pesado sea una simple agregación de columna, que el Storage Engine hace en un abrir y cerrar de ojos.
Técnica 4: reducir la cardinalidad siempre que sea posible
La velocidad de DAX depende directamente del número de valores distintos que los motores tienen que procesar. Columnas de altísima cardinalidad — marcas de tiempo al segundo, identificadores únicos largos — son el peor enemigo del rendimiento. Guardar la fecha separada de la hora, o redondear lo que no necesita precisión extrema, reduce la cardinalidad y acelera todo lo que se apoya en esas columnas. Es una optimización en el modelo que se refleja en todas las medidas.
Técnica 5: medir, no adivinar
La regla más importante de todas: nunca optimices a ciegas. Power BI tiene el Performance Analyzer, que muestra exactamente cuánto tardan cada visual y cada medida. Para ir más a fondo, herramientas gratuitas como DAX Studio revelan cuánto tiempo se pasó en el Storage Engine y cuánto en el Formula Engine — la información que apunta directamente al problema. Optimizar sin medir es como operar sin diagnóstico: se pierde tiempo arreglando lo que no estaba roto.
Un caso concreto: de treinta segundos a menos de uno
Un equipo tenía un informe donde una medida de "clientes distintos con compra en el período" tardaba cerca de treinta segundos en abrir. La medida usaba un FILTER sobre la tabla de ventas entera, con millones de filas, dentro de un iterador. Al correr el Performance Analyzer, vieron que casi todo el tiempo se pasaba en el Formula Engine. Reescribieron la medida para aplicar el filtro directamente a la columna y sustituir el iterador por una agregación nativa. El trabajo pesado pasó al Storage Engine. El tiempo de cálculo cayó de treinta segundos a menos de uno. El modelo no cambió, los datos no cambiaron — cambió la forma en que la medida pedía el trabajo.
El patrón mental que resuelve la mayoría de los casos
Si hubiera una única idea para llevar, sería esta: pregunta siempre "¿este cálculo se está haciendo columna a columna por el motor rápido, o fila a fila por el motor lento?". Cuando notes una medida lenta, busca los iteradores y los filtros sobre tablas enteras — son los sospechosos habituales. Reformula para que el Storage Engine haga el grueso, y la velocidad aparece casi siempre. Es menos sobre trucos y más sobre respetar cómo piensa la herramienta.
En la práctica
La próxima vez que un informe se arrastre, no culpes a Power BI antes de mirar tus medidas con estos ojos. Corre el Performance Analyzer, encuentra la medida más lenta, y pregunta dónde está haciendo trabajo de más. Muchas veces, una reescritura de dos líneas transforma la experiencia de todos los que usan el informe. ¿Cuál es la medida más lenta de tu informe principal — y ya mediste dónde pierde tiempo?
