Una de las cosas que suelo realizar cuando estoy probando cierto software es observar detalladamente su rendimiento (consumo de CPU, RAM, context switches, etc.). En esta ocasión le tocó el turno al Reproductor de Windows Media 11. Con el reproductor abierto y Process Explorer configurado para mostrar la lista de procesos ordenada por incremento de context switches, me encontré con lo siguiente:
Es decir, en ese momento el proceso Wmplayer.exe estaba situado el tercero de la lista con nada más y nada menos que 286 Context Switch Delta. El consumo de CPU es claramente nulo, pero eso no indica que todo vaya bien, ¿qué estaría haciendo el reproductor para generar una cantidad tan enorme de context switches cada poco tiempo? Un primer candidato son los accesos al registro de manera continuada, lo que se conoce como registry polling, algo totalmente evitable pues el sistema operativo ya proporciona mecanismos para informar a las aplicaciones si una clave del registro cambió o no, haga clic aquí para obtener más información. Seguidamente me puse a analizar el sistema con Regmon, que esclareció totalmente el asunto:
Como ven, el reproductor estaba modificando un valor del Registro ¡decenas de veces cada segundo! Supongo que esto se debía a un error de diseño de alguna parte del reproductor. Si tiene curiosidad, el valor implicado es HKCU\Software\Microsoft\MediaPlayer\Preferences\BackgroundScanCompleteDate, que apareció por vez primera en la versión 10 del reproductor y que, con casi toda probabilidad, se encarga de llevar un control de la última vez que se ha examinado la biblioteca multimedia con el fin de rellenar sus campos. En la versión 10 del reproductor sólo se modifica ese valor una vez por ejecución de la aplicación.
Estado actual del problema
Me puse en contacto con el equipo de Windows Media y, consecuentemente, el problema ya está corregido en una versión interna, posterior a Beta 2.
Este es un ejemplo para que observe que incluso Microsoft a veces utiliza métodos no muy "elegantes" en su software que atentan contra el rendimiento del mismo. Mark Russinovich ya analizó otros casos similares en esta entrada de su blog, y esta otra.
