Medir antes de cambiar

1144. Identidad de la lección

Módulo

3.7 — GPU y rendimiento

Lección

Medir antes de cambiar

Tipo académico

Laboratorio de depuración

Tipo de esquema

Práctica

Orden

Lección 2 del módulo

Tiempo estimado

45–60 minutos

Esta lección convierte un problema de rendimiento en una investigación acotada. Medirás un escenario repetible, distinguirás la evidencia de GPU del tiempo total de frame, priorizarás posibles intervenciones, probarás un cambio aislado y decidirás qué hacer a partir de los resultados.

1145. Objetivo de aprendizaje

Al terminar esta lección, podrás elaborar un registro de mediciones, distinguir el tiempo de frame de GPU del tiempo total de frame y seleccionar el cambio de rendimiento mínimo que esté justificado por la evidencia del profiler.

1146. Por qué importa

El trabajo de rendimiento se encarece cuando cada problema visible provoca un cambio de código, configuración o recursos sin medición previa. Un profiler aporta observaciones, pero estas solo resultan útiles cuando se obtienen en un contexto repetible y se vinculan con una decisión comprobable.

El tiempo de frame de GPU y el tiempo total de frame describen restricciones relacionadas, pero distintas. Mejorar el tiempo de GPU no demuestra que el tiempo total haya mejorado lo suficiente, y un tiempo de GPU aceptable no demuestra que el frame completo cumpla su presupuesto. Formula la hipótesis, recoge mediciones comparables, aísla una intervención y toma la decisión a partir del registro, no de la intuición ni de una conclusión generada por IA.

1147. Conocimientos previos

Ya deberías poder:

• identificar una categoría de presupuesto, su umbral, contexto, método de evidencia y respuesta a partir de 3.7 L1 — Un presupuesto es una herramienta de decisión;
• ejecutar el proyecto en una escena o situación de prueba representativa;
• localizar una métrica relevante de GPU o de tiempo de frame en el profiler disponible;
• expresar el requisito visual o de jugabilidad que debe conservarse;
• usar el flujo de trabajo de Git del proyecto para identificar un cambio aislado sin hacer push automáticamente.

Si el proyecto no tiene una situación de prueba fiable, crea una pequeña y repetible en lugar de iniciar una optimización general.

1148. Concepto central

Primero perfila, después prioriza y solo entonces cambia.

Una intervención de rendimiento solo está justificada cuando existen tres conexiones:

1. Observación: las mediciones repetidas muestran un incumplimiento del presupuesto.
2. Hipótesis: una causa plausible relaciona una categoría o condición medida con ese incumplimiento.
3. Intervención: un cambio acotado pone a prueba la hipótesis con un riesgo aceptable.

El tiempo de frame de GPU se refiere al tiempo medido que se atribuye al procesamiento gráfico en el contexto de prueba. El tiempo total de frame se refiere al tiempo más amplio necesario para completar un frame. Una escena puede estar limitada a la vez por la GPU y por otros trabajos. También puede mostrar un tiempo de GPU aceptable mientras el tiempo total sigue fuera del objetivo. Etiqueta cada métrica y no uses una como prueba de la otra.

El resultado del profiler reduce el espacio de investigación. No es una orden de optimizar todo lo que aparece en pantalla.

1149. Modelo mental

Usa Medir → Explicar → Priorizar → Cambiar → Volver a medir:

Mantén una comparación justa. Usa la misma escena, cámara o recorrido del jugador, ajustes de calidad, resolución, hardware o contexto del navegador, ventana de muestreo y método de medición siempre que sea posible. Registra por separado el tiempo de frame de GPU y el tiempo total de frame cuando ambos estén disponibles. Si cambia el contexto, etiqueta el nuevo resultado y no lo presentes como una comparación directa.

La IA puede ayudar a organizar observaciones, detectar contexto ausente o redactar una hipótesis falsable. No decide si la intervención funcionó. Esa decisión debe basarse en la evidencia de antes y después y en el requisito que el proyecto debe conservar.

1150. Ejemplo resuelto

Supón que una escena de combate tiene un objetivo de tiempo de frame de GPU de 16,7 ms o menos. Registras cinco muestras durante el mismo recorrido de cámara de 20 segundos:

El profiler muestra que los pases de partículas transparentes forman una categoría importante de GPU durante la ráfaga. Esto respalda una hipótesis sobre el coste de GPU del efecto, pero no explica cada milisegundo del tiempo total de frame.

Considera tres intervenciones:

1. eliminar por completo el efecto;
2. reducir el número de partículas y comparar el resultado visual;
3. reescribir código de jugabilidad no relacionado.

La segunda es la prueba mínima justificada porque responde directamente a la categoría observada y conserva el propósito del efecto. Registra la referencia actual de Git, aplica solo esa intervención, registra la nueva referencia y repite el mismo recorrido.

Si el tiempo de GPU disminuye pero el tiempo total sigue fuera del objetivo, informa de ambos hechos. Si el efecto deja de ser legible, la intervención no funciona por el mero hecho de haber mejorado una métrica. Tanto la evidencia de rendimiento como el requisito visual o de jugabilidad deben orientar la decisión.

1151. Flujo de trabajo asistido por IA

Usa la IA para apoyar la formulación de hipótesis y la disciplina de medición, no para obtener conclusiones.

1. Proporciona el presupuesto, el contexto de prueba, los nombres de las métricas, las mediciones de referencia, la observación relevante del profiler y el requisito que debe conservarse.
2. Pide a la IA que reformule la evidencia, identifique el contexto que falta y proponga una hipótesis falsable.
3. Pídele que organice posibles intervenciones según el impacto esperado, el riesgo y la reversibilidad. Trata el resultado como una lista de opciones.
4. Selecciona y aplica un único cambio acotado mediante el flujo de trabajo establecido para el proyecto.
5. Proporciona las mediciones etiquetadas de antes y después y pide a la IA que organice una comparación o detecte preguntas sin resolver. Comprueba personalmente cada interpretación contra el registro.

Ejemplo de prompt:

Este es el presupuesto de rendimiento y el contexto fijo de prueba: [contexto]. Estas son las mediciones de referencia, etiquetadas como tiempo de frame de GPU y tiempo total de frame cuando estén disponibles: [datos]. El profiler muestra [categoría observada]. Reformula la evidencia, identifica el contexto que falta, formula una hipótesis falsable y ordena tres intervenciones reversibles por impacto esperado y riesgo. No declares que la prueba tuvo éxito ni propongas refactorizaciones no relacionadas.

La salida de la IA sigue siendo una nota de trabajo. El registro de mediciones, la evidencia del profiler, el cambio aislado y tu comparación respaldan la decisión.

1152. Límite del cambio en Git

Usa Git para identificar la intervención aislada, no como sustituto del profiling.

1. Inspecciona el árbol de trabajo y registra la referencia o el punto de control inicial.
2. Excluye del experimento las ediciones no relacionadas o documéntalas y mantenlas separadas.
3. Aplica una sola intervención acotada.
4. Registra la referencia o el punto de control posterior y enumera los archivos o ajustes modificados. No hagas push como parte del laboratorio.
5. Si rechazas la intervención, usa el límite registrado para restaurarla sin descartar trabajo ajeno al experimento.

1153. Evaluación práctica

Completa la evaluación práctica adjunta, Intervención de rendimiento basada en evidencias.

La entrega debe incluir:

• el presupuesto y el contexto fijo de prueba;
• las mediciones de referencia y posteriores, con sus métricas etiquetadas;
• una observación del profiler y una hipótesis falsable;
• tres intervenciones priorizadas;
• una intervención aislada con referencias o puntos de control de Git de antes y después;
• una comparación que distinga el tiempo de frame de GPU del tiempo total de frame;
• una decisión de conservar, revertir o investigar más, vinculada con la evidencia;
• la confirmación de si se mantuvo el resultado visual o de jugabilidad requerido.

1154. Errores comunes

Evita estos errores:

• tratar la categoría más grande de una captura como una causa raíz demostrada;
• medir un evento irrepetible o poco representativo;
• usar el tiempo de frame de GPU como sinónimo del tiempo total de frame;
• modificar varias variables entre las mediciones iniciales y posteriores;
• elegir una reescritura amplia antes de probar una intervención más pequeña y reversible;
• aceptar una interpretación de la IA sin contrastarla con la evidencia registrada;
• declarar que un cambio funciona cuando daña un resultado visual o de jugabilidad requerido.

1155. Lista de validación

1156. Puntos clave

• Un profiler aporta evidencia; no elige la intervención.
• El tiempo de frame de GPU y el tiempo total de frame están relacionados, pero son distintos.
• Un contexto repetible y unas etiquetas explícitas permiten comparaciones significativas.
• Prioriza las intervenciones antes de modificar el proyecto.
• Prueba un cambio pequeño y reversible cada vez.
• Conserva, revierte o investiga más según la evidencia registrada.

1157. Siguiente lección

Continúa con 3.8 L1 — Liberar recursos es una operación del ciclo de vida. La siguiente lección pasa de medir el coste de rendimiento a rastrear la propiedad de los recursos e identificar dónde falta su liberación a lo largo del ciclo de vida.

1158. Comprobación