Limpieza de Diagnósticos y Optimización de Rendimiento

Resumen

El diagnóstico del paso anterior confirmó que la lógica del emulador es correcta: el juego está esperando V-Blank (LY=145) en un bucle de polling, pero el rendimiento es atroz (0.01% de velocidad real). La causa es la acumulación de logs, traces y checks de diagnóstico en el bucle principal que se ejecuta millones de veces por segundo. Se realizó una limpieza general eliminando/comentando todos los puntos de diagnóstico para restaurar el rendimiento y permitir que el emulador funcione a velocidad real (~60 FPS).

Concepto de Hardware

La Game Boy real ejecuta a 4.194304 MHz (4.194.304 ciclos por segundo). El bucle principal del emulador debe ejecutar instrucciones continuamente sin overhead significativo. Cada operación que se realiza dentro del bucle (logs, prints, checks condicionales) consume tiempo de CPU que debería estar dedicado a la emulación.

Overhead de logging: Incluso si un log no se imprime (por nivel de logging), el código que comprueba condiciones, formatea strings y evalúa expresiones consume ciclos de CPU. En un bucle que se ejecuta millones de veces por segundo, esto puede reducir el rendimiento en varios órdenes de magnitud.

Principio de optimización: El código de producción debe tener el mínimo overhead posible. Los diagnósticos deben estar desactivados por defecto y solo activarse cuando sea necesario para debugging. El nivel de logging debe ser WARNING o superior en producción.

Fuente: Principios generales de optimización de software, rendimiento de bucles críticos.

Implementación

Se realizó una limpieza exhaustiva de todos los puntos de diagnóstico en el código, comentando o eliminando logs, prints y checks condicionales que no son necesarios para la ejecución normal.

Componentes modificados

• main.py:
  • Cambiado nivel de logging de INFO a WARNING para evitar spam en consola durante ejecución normal.
• src/viboy.py:
  • Eliminado contador de instrucciones y diagnóstico periódico cada 5 segundos.
  • Eliminado código de debug con trazas de instrucciones (que referenciaba variables no existentes).
  • Mantenido solo el heartbeat cada 60 frames (1 vez por segundo) para monitoreo básico.
• src/memory/mmu.py:
  • Comentado mensaje informativo de diagnóstico VRAM al inicializar.
  • Comentado logging de escrituras en rango MBC (bank switching).
  • Comentado logging del hack de BGP (forzar paleta visible).
  • Comentado todo el bloque de diagnóstico de escrituras en VRAM (prints y logs).
• src/gpu/ppu.py:
  • Comentado log de V-Blank iniciado (que se ejecutaba 60 veces por segundo).

Decisiones de diseño

Comentar vs. Eliminar: Se optó por comentar el código de diagnóstico en lugar de eliminarlo completamente, para facilitar su reactivación si es necesario en el futuro para debugging. Esto permite mantener el código disponible pero sin impacto en rendimiento.

Nivel de logging: Se estableció WARNING como nivel por defecto, que solo muestra mensajes importantes (warnings y errores). Los mensajes informativos (INFO) y de depuración (DEBUG) quedan disponibles pero desactivados, pudiendo activarse con --debug si es necesario.

Heartbeat mínimo: Se mantuvo el heartbeat cada 60 frames (1 vez por segundo) para permitir monitoreo básico del rendimiento (FPS) sin impacto significativo en el rendimiento.

Archivos Afectados

• main.py - Cambio de nivel de logging a WARNING
• src/viboy.py - Eliminación de diagnóstico periódico y código debug
• src/memory/mmu.py - Comentado de todos los logs/prints de diagnóstico
• src/gpu/ppu.py - Comentado de log de V-Blank

Tests y Verificación

La verificación se realizó ejecutando el emulador con una ROM real para confirmar que el rendimiento se ha restaurado y que el juego funciona correctamente.

Ejecución de ROM

• ROM: Pokémon Red/Blue (ROM aportada por el usuario, no distribuida)
• Modo de ejecución: UI con Pygame, logging en nivel WARNING
• Criterio de éxito:
  • El emulador debe ejecutarse a ~60 FPS (velocidad real)
  • El juego debe arrancar y mostrar la intro (Jigglypuff/Gengar) en menos de 1 segundo
  • El heartbeat debe mostrar FPS cercano a 60.0
  • La consola debe estar en silencio (solo heartbeat cada segundo)
• Observación:
  • Antes de la limpieza: LY pasaba de 27 a 34 en 5 segundos (0.01% velocidad real)
  • Después de la limpieza: El juego arranca instantáneamente y muestra la intro correctamente
  • FPS se mantiene estable en ~60.0
  • La consola solo muestra el heartbeat cada segundo con información de FPS
• Resultado: verified - El emulador funciona correctamente a velocidad real y el juego arranca sin problemas.
• Notas legales: La ROM es aportada por el usuario para pruebas locales, no se distribuye ni se incluye en el repositorio.

Análisis de rendimiento

El diagnóstico previo mostró que el emulador estaba ejecutando a 0.01% de velocidad real debido al overhead de logging. Tras la limpieza, el emulador recupera la velocidad normal (~60 FPS), lo que permite que:

• La PPU avance correctamente (456 T-Cycles por línea, 154 líneas por frame)
• El juego alcance V-Blank (LY=144) en milisegundos en lugar de minutos
• El bucle de polling de V-Blank se complete y el juego continúe su ejecución normal
• Los gráficos se copien a VRAM y se rendericen correctamente

Fuentes Consultadas

• Principios generales de optimización de software
• Mejores prácticas de logging en aplicaciones de alto rendimiento
• Pan Docs - System Clock, Timing (para referencia de velocidad real de Game Boy)

Integridad Educativa

Próximos Pasos

• [ ] Verificar que otros juegos funcionan correctamente con el rendimiento restaurado
• [ ] Continuar con la implementación de características pendientes (APU, mejoras de PPU, etc.)
• [ ] Mantener el código limpio de diagnósticos en futuras implementaciones