Cómo comparar correctamente la velocidad de versiones de un programa en Windows

Queremos comparar las versiones A y B de un programa en Windows. Lo peor que se puede hacer en ese momento es ejecutar cada una una sola vez en la misma máquina y decir «parece que B es un 8 % más rápida».

Ese 8 % podría ser realmente una diferencia de código. Pero, en la práctica, en los benchmarks de Windows es habitual que la causa real sea alguna de estas: el power mode, el power plan, el calor, las actualizaciones en segundo plano, la indexación de búsqueda, el análisis antivirus, la afinidad de procesador, el orden de ejecución o el estado de la caché. Descartarlas una por una es un trabajo poco vistoso, pero necesario.

En este artículo se resume cómo comparar la velocidad de ejecución de distintas versiones de un programa en Windows de la forma más cercana posible a una diferencia de código puro. Está pensado principalmente para Windows 11, pero la mayor parte de powercfg, start y comandos similares funciona igual en Windows 10.

Términos que conviene tener claros de antemano

En el cuerpo del artículo aparecen algunos términos que se dejan en inglés. Para que no den problemas la primera vez que se mencionan, se resumen aquí de antemano.

Primero, la conclusión

Si se lleva al extremo, la clave para aumentar la reproducibilidad se reduce a estos seis puntos.

1. Decidir primero «qué se quiere comparar» El entorno que hay que igualar cambia según si se quiere observar la diferencia de código o la experiencia real del usuario.

2. Registrar el power mode y el power plan como cosas distintas En Windows, si se trata esto con descuido, la comparación termina convirtiéndose en una comparación de las políticas de ahorro de energía del sistema operativo.

3. Separar la primera ejecución en frío del estado estable una vez caliente No es raro que solo la primera ejecución sea rápida, o que solo las últimas sean lentas.

4. Alternar en el orden A→B→A→B Si se ejecuta primero todo A y después todo B, se arrastra el sesgo del calor y del estado del segundo plano.

5. Observar no solo el promedio, sino también la mediana y la dispersión Un solo valor atípico puede desbaratar la visión de conjunto. El promedio es más frágil de lo que parece.

6. Si la diferencia es pequeña, profundizar en la causa con ETW / WPR Si se discute solo a partir de la sensación subjetiva, ambas posturas quedan sin respaldo y la conversación no converge.

Decidir primero qué se quiere comparar

Aunque se hable de «comparación de velocidad» en general, en realidad hay dos tipos.

1. Comparación para ver la diferencia de código

Es la comparación con la que se quiere saber si la implementación en sí se ha vuelto más rápida debido a cambios de algoritmo, cambios de estructura de datos, optimizaciones del compilador, actualizaciones del runtime, etc.

En este caso, hay que reducir todo lo posible el ruido del entorno. Se usa una sesión dedicada al benchmark, se fija el power mode, se detienen las notificaciones, se suprime la indexación de búsqueda y la sincronización y, si hace falta, se llega incluso a un clean boot.

2. Comparación para ver la experiencia real del usuario

Es la comparación con la que se quiere saber la velocidad que percibirá el usuario en su Windows habitual después de distribuir el programa.

En este caso, no hay que eliminar todo el ruido que existe en la realidad. Comparar en un «entorno cotidiano realista» que incluya la sincronización de OneDrive, Defender, las notificaciones y la configuración de energía habitual da un resultado más cercano a la realidad.

Si se mezclan estos dos tipos, la conclusión sale torcida. Es normal que pasen cosas como «en el laboratorio es un 12 % más rápido, pero en la realidad la diferencia está dentro del margen de error» o «en la realidad es más rápido, pero el tiempo de CPU no cambia».

Las principales causas de que los resultados varíen en Windows

Primero, se resume a grandes rasgos qué es lo que hace variar los resultados.

En resumen, incluso con «la misma máquina Windows», si las condiciones no coinciden, se trata de un experimento distinto.

Separar el power mode y el power plan

Este punto es bastante importante.

En Windows conviven el Power mode de la app Configuración y el tradicional Power plan (el plan de energía que se ve con powercfg). Como se parecen a simple vista, se tiende a mezclarlos, pero si se tratan sin cuidado, la comparación se vuelve un caos.

En la app Configuración de Windows, el Power mode se elige desde Settings > System > Power & battery. Según la documentación de Microsoft, se puede alternar entre Best power efficiency, Balanced y Best performance, tanto para Plugged in como para On Battery. Además, al cambiar el Power mode también cambia la configuración de energía subyacente y el comportamiento del PPM (Processor Power Management). Es decir, esta sola diferencia puede cambiar la política de aparcamiento de núcleos y de escalado de rendimiento.

Por otro lado, el Power plan es el plan de energía tradicional, como Balanced o High performance. Se puede consultar con powercfg /list o powercfg /getactivescheme.

Lo complicado aquí es que en Windows existen tanto la superposición (overlay) del power mode como el power plan. Si se representa la relación en un diagrama, queda así.

flowchart TB
    accTitle: Relación entre el power mode y el power plan en Windows
    accDescr: Diagrama que muestra que la app Configuración controla la capa superior del power mode (overlay) con las opciones Best power efficiency, Balanced y Best performance, mientras que powercfg controla la capa inferior del power plan con Balanced, High performance y custom plan; ambas capas, junto con si el equipo está en CA o batería, determinan la configuración de energía que realmente se aplica (PPM y el subgrupo de gráficos), la cual define el límite de frecuencia, el aparcamiento de núcleos y el escalado de rendimiento
    subgraph upper["Capa superior: Power mode - overlay"]
        direction LR
        M1["Best power efficiency"]
        M2["Balanced"]
        M3["Best performance"]
    end

    subgraph lower["Capa inferior: Power plan - plan de energía"]
        direction LR
        P1["Balanced"]
        P2["High performance"]
        P3["custom plan"]
    end

    UI["App Configuración<br/>Power mode en Power and battery"] --> upper
    CLI["powercfg /setactive para cambiar"] --> lower
    upper --> PPM["Configuración de energía realmente aplicada<br/>PPM y el subgrupo de gráficos"]
    lower --> PPM
    AC["Alimentación de CA o batería"] --> PPM
    PPM --> RESULT["Límite de frecuencia / aparcamiento de núcleos / escalado de rendimiento"]

Si solo se mira la capa superior o solo la inferior, no queda determinado el comportamiento real. Por eso, en los resultados del benchmark hay que registrar como mínimo lo siguiente.

• Si estaba conectado a CA o con batería
• Cuál era el Power mode
• Cuál era el Active power plan

Un resultado de benchmark que no incluya estos tres datos no permite reconstruir las condiciones cuando se revisa más adelante.

Las condiciones de energía que hay que fijar primero

1. En los portátiles, comparar siempre con conexión a CA El funcionamiento con batería tiende a introducir limitaciones no deseadas.

2. Fijar el Power mode Para fines de benchmark, lo primero es probar con Best performance.

3. Registrar el Active power plan Se deja constancia del valor actual con powercfg.

powercfg /list
powercfg /getactivescheme

La documentación de Microsoft muestra la salida de powercfg /list con este formato. Al final de la línea del plan activo aparece un *. En un entorno con Windows en japonés, el encabezado y el nombre del plan salen en japonés.

Existing Power Schemes (* Active)
-----------------------------------
Power Scheme GUID: {guidPlan1}  (Balanced) *
Power Scheme GUID: {guidPlan2}  (Power saver)

El GUID que aparece aquí se copia tal cual en el campo power_plan del archivo de resultados. Lo importante es guardar el GUID, no el nombre, porque incluso un plan que se llame igual «Balanced» puede ser en realidad otro plan duplicado o personalizado.

1. Cambiar a High performance si hace falta

# Balanced
powercfg /setactive 381b4222-f694-41f0-9685-ff5bb260df2e

# High performance
powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

¿Se puede cambiar el Power mode desde la línea de comandos?

Este es un punto donde es fácil atascarse. En la lista pública de opciones de línea de comandos de powercfg no existe una opción para volver a elegir el propio Power mode (overlay). El procedimiento oficial para cambiarlo es hacerlo desde Settings > System > Power & battery en la app Configuración.

Por otro lado, powercfg sí admite leer y escribir los valores de configuración del esquema de overlay. La documentación indica lo siguiente.

• Si se pasa el alias del overlay y el subgrupo a powercfg /q, se puede leer la configuración del overlay
• powercfg /setacvalueindex y /setdcvalueindex también se pueden usar con el esquema de overlay
• Si no se especifica un esquema, se toma como objetivo el overlay actualmente activo (o el power plan actual si no hay overlay)
• La lista de alias se puede consultar con powercfg /aliases

Es decir, lo que se puede hacer por línea de comandos es «leer y ajustar el contenido del overlay que está activo en ese momento», no cambiar «qué overlay se elige». Como procedimiento reproducible para el benchmark, lo más realista es fijar el Power mode a mano desde la app Configuración y dejar ese valor escrito en el resultado. En el procedimiento hay que anotar explícitamente algo como «se configuró Power mode = Best performance» y confirmarlo en pantalla cada vez que se ejecute.

Que no aparezca «High performance» es algo normal

Este es otro punto donde es fácil quedarse atascado. Según la documentación de Microsoft, en los dispositivos compatibles con Modern Standby solo se permite Balanced, o un plan derivado de Balanced. Por lo tanto, en lugar de pensar «no encuentro High performance, ¿está roto?», es posible que ese modelo esté diseñado así.

Además, Microsoft indica que, si no se puede cambiar el Power mode, es posible que esté seleccionado un custom power plan, por lo que conviene probar primero a seleccionar Balanced. Cuando la interfaz del Power mode no responde, sospechar de esto es lo más rápido.

Eliminar el ruido en segundo plano

Windows sigue ejecutando actualizaciones, indexación o análisis en segundo plano incluso cuando queremos medir en silencio. Lo primero es reducir esa cantidad.

Primero reiniciar y esperar a que todo se calme

Después de cambiar la configuración, hay que reiniciar una vez y, tras iniciar sesión, esperar unos minutos antes de empezar a ejecutar nada. Justo después del arranque, las actualizaciones, la indexación, la sincronización, Defender y los distintos programas residentes todavía están muy activos.

Para una comparación estricta, usar clean boot

Microsoft describe un procedimiento para llegar, mediante clean boot, a una configuración de inicio mínima. Consiste en detener los servicios que no son de Microsoft desde msconfig y deshabilitar las Startup apps desde el Administrador de tareas (Task Manager).

Esto es muy eficaz para reducir el ruido. Sin embargo, se aleja del entorno de uso cotidiano, así que conviene reservarlo para la «comparación de laboratorio orientada a ver la diferencia de código».

Silenciar las notificaciones

Los banners de notificación de Windows parecen poca cosa, pero en realidad molestan bastante. No solo estorban visualmente: también pueden alterar el momento de ejecución, el foco y la actividad de las aplicaciones en segundo plano.

Hay que activar manualmente Do not disturb, o al menos desactivar las notificaciones mientras dura el benchmark.

Contener la indexación de búsqueda y la sincronización

Si lo que se está midiendo es del tipo que lee muchos archivos, genera muchos archivos de salida o reconstruye el árbol de código fuente repetidas veces, la indexación de búsqueda y la sincronización en la nube afectan de forma discreta pero real.

• Excluir el directorio del benchmark de la indexación de búsqueda
• Detener la sincronización de OneDrive, Dropbox, Google Drive, etc.
• Cerrar el navegador, Teams, Discord y Slack

Nada de esto es llamativo, pero cuando importa, importa mucho.

Una comparación sin igualar el calor suele terminar comparando el calor

La frecuencia de funcionamiento de la CPU y la GPU cambia entre cuando están frías y cuando ya se han calentado. Eso significa que, aunque el código sea el mismo, las condiciones cambian en cada ejecución. Esto es especialmente notable en portátiles, mini PC delgados y equipos de escritorio pequeños.

Reglas que hay que respetar

• Igualar la temperatura ambiente en la medida de lo posible
• Fijar la forma de colocar el portátil
• Fijar la configuración del adaptador de CA, el dock y los monitores externos
• No realizar tareas pesadas antes del benchmark
• Medir por separado la primera ejecución y el estado estable

Alternar el orden de ejecución

Hay que evitar hacer 10 corridas de A y luego 10 de B, porque así se arrastra el sesgo del calor, la caché y la actividad en segundo plano.

Se recomienda alguna de las siguientes opciones.

• A B A B A B ...
• A B B A A B B A ...
• Generar de antemano un orden aleatorio y ejecutar en ese orden

Lo que significa «rápido» cambia según qué se mida

Si se intenta reducir «rápido» a un único número, casi siempre sale mal. Las tres métricas representativas que conviene mirar en Windows son las siguientes.

1. Wall-clock time (tiempo real)

Es el tiempo que espera el usuario. Es lo más cercano a la percepción de extremo a extremo, así que es el primer valor que conviene mirar.

En Windows, QueryPerformanceCounter (QPC) se puede usar para obtener marcas de tiempo de alta resolución. En código administrado (managed code), lo habitual es usar la familia Stopwatch. Mirar los milisegundos con DateTime.Now es, la verdad, un poco arriesgado.

2. CPU time (tiempo de usuario + tiempo de kernel)

Es el tiempo que el proceso realmente ha usado la CPU, y se obtiene con GetProcessTimes.

Es útil para observar la eficiencia de cálculo. Por ejemplo, si el wall-clock mejora pero el CPU time no cambia, es posible que lo que esté influyendo sea la caché, la E/S, el tiempo de espera o la planificación.

3. Cycle count (número de ciclos de CPU)

Con QueryProcessCycleTime se puede obtener el número total de ciclos de CPU de todo el proceso.

Esta también es una métrica de trabajo de CPU (CPU work), pero muestra una faceta distinta del wall-clock. Es especialmente útil cuando se quiere ver si «el tiempo de espera es el mismo, pero la parte de cálculo se ha aligerado».

priority, affinity y NUMA son el último recurso

Estos ajustes a veces surten efecto. Pero, aunque surtan efecto, si se tocan desde el principio, es fácil acabar generando otro fenómeno distinto.

Primero, medir de forma normal

Si ya aparece una diferencia en el estado predeterminado, esa diferencia en sí misma tiene valor. Introducir /high o /affinity desde el principio implica traer «condiciones que no se dan en un Windows real».

Si se usan, dejar claro el objetivo

• /high: se quiere reducir la interferencia de otros procesos
• /affinity: se quiere fijar la asignación de CPU para comparar
• Control de NUMA: en una máquina grande, se quiere igualar incluso la localidad de memoria

El comando start de Windows permite iniciar un proceso indicando la priority class o la affinity mask.

start "" /high /wait myapp.exe --bench case1.json
start "" /affinity F /high /wait myapp.exe --bench case1.json

Sin embargo, evitar /realtime

/realtime se puede usar, pero es mejor no usarlo. En lugar de eliminar ruido, tiende a generar otro tipo de problema.

Procedimiento de medición recomendado

Con todo lo anterior en cuenta, se resume un procedimiento fácil de aplicar en la práctica.

Procedimiento orientado a la comparación de laboratorio

1. Fijar el objeto de comparación
   • commit hash / build number
   • compiler / runtime version
   • Debug / Release
   • Presencia de logs, assert y trazas
2. Fijar las condiciones de la máquina
   • Build de Windows
   • Versión de BIOS / UEFI
   • Versión de los controladores
   • Conexión a CA
   • Temperatura ambiente y forma de colocación
3. Fijar las condiciones de energía
   • Decidir el Power mode
   • Registrar el Active power plan
4. Reiniciar
5. Esperar unos minutos antes del benchmark
6. Usar clean boot si hace falta
7. Incluir un warm-up
8. Alternar A / B
9. Asegurar suficientes repeticiones
10. Guardar la mediana, el mínimo, el máximo y el p95
11. Guardar los raw data
12. Si la diferencia es pequeña, tomar una traza con ETW / WPR

Cuántas veces repetir

También conviene fijar una referencia para el punto 9, «asegurar suficientes repeticiones». Lo que sigue no es una solución estadísticamente rigurosa, sino un punto de partida práctico.

El tiempo total se puede estimar con tiempo de una ejecución × número de repeticiones × número de versiones + warm-up. Si un proceso de 30 segundos se ejecuta 30 veces para A y 30 para B, el cálculo da alrededor de 35 minutos incluyendo el warm-up. Si esto no resulta realista, en lugar de reducir el número de repeticiones, tiene más sentido recortar el alcance de lo que se mide (aislar solo el paso pesado).

Si cuesta decidir cuándo parar, una forma sencilla es ir aumentando las repeticiones mientras se observa la evolución de la mediana, y detenerse en el punto en que ya no se mueve aunque se sigan añadiendo repeticiones.

Datos que conviene registrar porque ayudan más adelante

En el CSV o JSON del benchmark, es muy recomendable dejar constancia al menos de lo siguiente.

timestamp,version,scenario,elapsed_ms,user_ms,kernel_ms,cycles,power_mode,power_plan,ac_or_dc,room_temp_c,notes

Si es posible, también conviene añadir lo siguiente.

cpu_package_temp_start_c,cpu_package_temp_end_c,affinity_mask,priority_class,windows_build,driver_version

En un benchmark, a veces es más importante poder interpretarlo después que el propio hecho de medir.

Observar no solo el promedio, sino también la mediana y la distribución

El promedio es cómodo, pero en un benchmark de Windows se rompe con facilidad. Basta con que Defender entre en acción una sola vez, salga una notificación o que otro proceso golpee el SSD, para que el promedio se desvíe.

Se recomienda esta combinación.

• Mediana: es lo primero que hay que mirar
• p95 / p99: para ver si empeora la cola (tail)
• min / max: para ver cómo se comportan los extremos
• Diagramas de caja y de dispersión: útiles cuando la diferencia es pequeña

Cómo interpretar los resultados cuando aparece una diferencia

La interpretación de los resultados se entiende mejor si se observa en combinación.

Solo el wall-clock es más rápido

Puede tratarse de una mejora en la E/S, el tiempo de espera, la caché o la planificación.

También bajan el CPU time y el cycle count

Es muy probable que la implementación en sí se haya aligerado.

Solo la primera ejecución es lenta o rápida

Es la diferencia entre frío (cold) y caliente (warm). Hay que sospechar del arranque, la inicialización, la generación de caché y el JIT.

Se vuelve más lento cuantas más veces se repite

Hay que sospechar del calor, el throttling, la presión de memoria y la actividad en segundo plano.

Profundizar con ETW / WPR hasta entender «por qué es más rápido»

Cuando la diferencia es pequeña o no se logra entender el motivo, el camino habitual es pasar a las herramientas de la familia ETW (Event Tracing for Windows) de Windows.

El Windows Performance Recorder (WPR) de Microsoft es una herramienta de grabación basada en ETW, incluida en el Windows ADK. Permite capturar de forma conjunta la CPU, la E/S, los context switch, los page faults y más.

Como mínimo, el uso sería algo así.

wpr -start CPU -filemode

REM Aquí se ejecuta el benchmark

wpr -stop trace.etl

Una vez abierto en WPA, las gráficas que conviene mirar primero suelen ser siempre las mismas.

Al comparar, lo básico es tomar una traza de A y otra de B con el mismo escenario, y ver las mismas gráficas una al lado de la otra. Con una sola traza no se puede juzgar si algo «es lento».

Llegados a este punto, en lugar de decir «B es un 3 % más rápido», se puede hablar con motivos concretos, como «en B se reduce la espera por lock y baja el ready time» o «en A aumentan las aperturas de archivo y el cold start es más lento».

Lista de comprobación resumida en una página

Para terminar, se deja en un formato que se puede pegar directamente en un procedimiento.

Fijar

• Se fijó el objeto de comparación (commit hash / build number / Debug o Release / condiciones de compilación como PGO / presencia de logs y assert)
• El portátil se conectó a CA
• Se fijó el Power mode desde la app Configuración
• Se comprobó el Active power plan con powercfg /getactivescheme
• Se detuvieron las notificaciones. Se detuvieron la indexación de búsqueda y la sincronización en la nube
• Se usó clean boot si hacía falta
• Se reinició y se esperó unos minutos antes de empezar

Ejecutar

• Se incluyó un warm-up
• Se midieron por separado cold (primera ejecución) y warm (estado estable)
• Se alternó A / B, o se ejecutó en orden aleatorio
• Se ejecutó un número de repeticiones decidido de antemano (referencia en la tabla anterior)

Registrar

• Se guardaron los raw data con una fila por ejecución (elapsed_ms / user_ms / kernel_ms / cycles)
• Se registraron CA o batería, el Power mode, el GUID del power plan, el Windows build y la versión de los controladores
• Se registraron la temperatura ambiente y la disposición del equipo
• También se dejaron por escrito las condiciones que no se fijaron

Interpretar

• Se observó la mediana. No se juzgó solo por el promedio
• Se observó la cola (tail) con p95 / p99
• Se comprobaron los valores atípicos con min / max
• Se dedujo el motivo combinando wall-clock, CPU time y cycle count
• Cuando la diferencia era pequeña, se profundizó hasta ETW / WPR

Resumen

A la hora de comparar versiones distintas de un programa en Windows, lo que realmente funciona no son trucos llamativos. Lo importante son prácticas como las siguientes, poco vistosas pero eficaces para la reproducibilidad.

• Fijar y registrar CA / Power mode / power plan
• Separar cold y warm
• Alternar A / B
• Observar la mediana y la distribución
• Usar clean boot si hace falta
• Si la diferencia es pequeña, profundizar el motivo con ETW / WPR

Y lo más importante de todo es anotar, junto con el resultado, qué se fijó y qué no se fijó. Un benchmark es, a la vez, una comparación de velocidad y un registro de las condiciones del experimento.

Un informe de mejora de velocidad sin las condiciones anotadas no permite que otra persona compruebe si puede obtener el mismo resultado, porque solo quedan los números y no queda ningún medio para reproducirlos. Por el contrario, si las condiciones están bien documentadas, aunque la diferencia sea pequeña, el resultado tiene un valor genuino.

Referencias

• Microsoft Support: Cambiar el modo de energía de tu PC con Windows
• Microsoft Learn: Configuración de las directivas de energía (Power Policy Settings)
• Microsoft Learn: Personalizar el control deslizante de energía y rendimiento de Windows
• Microsoft Learn: Opciones de línea de comandos de Powercfg
• Microsoft Support: Cómo realizar un clean boot en Windows
• Microsoft Support: Notificaciones y Do Not Disturb en Windows
• Microsoft Support: Indexación de búsqueda en Windows
• Microsoft Learn: Configurar exclusiones personalizadas para Microsoft Defender Antivirus
• Microsoft Support: Seguridad del dispositivo en la app Seguridad de Windows
• Microsoft Learn: Función QueryPerformanceCounter
• Microsoft Learn: Obtener marcas de tiempo de alta resolución
• Microsoft Learn: Función GetProcessTimes
• Microsoft Learn: Función QueryProcessCycleTime
• Microsoft Learn: Comando start
• Microsoft Learn: Función SetPriorityClass
• Microsoft Learn: Función SetProcessAffinityMask
• Microsoft Learn: Grupos de procesadores (Processor Groups)
• Microsoft Learn: Windows Performance Recorder
• Microsoft Learn: Opciones de línea de comandos de WPR
• Microsoft Learn: Análisis de CPU en Windows Performance Analyzer - Qué gráfica mirar para ver cada cosa.
• Microsoft Learn: Establecer el plan de energía predeterminado - Ejemplo de salida de powercfg -LIST.

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Cuáles son las principales causas de que los resultados de un benchmark varíen en Windows?

Hay factores en múltiples capas: el power mode, el power plan, el calor, las actualizaciones en segundo plano, la indexación de búsqueda, el análisis antivirus, la prioridad y la afinidad, el orden de ejecución y el estado de la caché, entre otros. Incluso en la misma máquina Windows, si estas condiciones no coinciden, en la práctica se trata de un experimento distinto. En los portátiles en particular, el comportamiento cambia mucho según si están conectados a la corriente o funcionando con batería, por lo que es fundamental comparar siempre con alimentación de CA y dejar registradas las condiciones.

¿Cuál es la diferencia entre power mode y power plan?

El power mode es la opción que se elige en Power & battery de la app Configuración, entre Best power efficiency, Balanced y Best performance, y afecta la configuración de energía subyacente y el comportamiento del PPM (Processor Power Management). El power plan es el plan de energía tradicional, como Balanced o High performance, que se consulta con powercfg. Como en Windows existen ambos, en los resultados del benchmark hay que registrar, como mínimo, tres datos: si estaba conectado a CA o con batería, el power mode y el power plan activo.

¿Es una avería que no aparezca el plan de energía High performance?

Lo más probable es que no sea una avería. Según la documentación de Microsoft, en los dispositivos compatibles con Modern Standby solo se permite Balanced, o un plan derivado de Balanced. Es decir, es normal que ese modelo, por diseño, no ofrezca High performance. Además, si la interfaz de Power mode no se puede cambiar, es posible que esté seleccionado un custom power plan, así que lo más rápido es probar primero a seleccionar Balanced.

¿En qué orden se debe ejecutar la comparación de velocidad entre la versión A y la versión B?

Debe evitarse ejecutar primero todas las corridas de A y después todas las de B, porque el sesgo de calor, caché y actividad en segundo plano recaería solo sobre uno de los dos. Lo recomendable es alternar A B A B, o ejecutar según un orden aleatorio generado de antemano. Además, conviene medir por separado la primera ejecución en frío y el estado estable una vez que el sistema ya está caliente, y observar no solo el promedio sino también la mediana, el p95, el mínimo y el máximo, para evitar que un valor atípico distorsione el resultado.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.