Analizar el rendimiento de una carga acotada con GitHub Copilot

Un agente puede sugerir un cuello de botella. Solo una medición puede mostrar lo ocurrido con tu carga de trabajo. Un resultado válido puede ser ninguna mejora medible.

Resumen del laboratorio

[!NOTE] Un resultado inconcluso es mejor que un tiempo fabricado.

Conceptos · Primera tarea · Lista de evidencias · Restablecer

Objetivos de aprendizaje

• Define un límite de medición antes de optimizar.
• Conserva la salida funcional mientras comparas un único cambio.
• Distingue tiempo transcurrido, asignaciones, memoria retenida y memoria máxima.
• Evita pruebas de carga, concurrencia sin límites y conjuntos de datos grandes en una máquina compartida.

Antes de empezar

Prepara 10-profiling con la configuración de recursos limitados. El fixture predeterminado es el pequeño DataAnalyzerReporter. Los ejemplos importados de ContosoOnlineStore y mediciones comparativas son una ampliación opcional en una máquina aislada, no parte de la ejecución predeterminada. No inicies aquí BenchmarkDotNet, una prueba de carga ni una expansión de solicitudes en paralelo.

Conceptos y casos de uso

La demostración actual inicia su cronómetro después de cargar la entrada. Por tanto, la duración que muestra no mide la carga de archivos. Explica esa limitación antes de cambiar FileLoader.

Escenario del ejercicio

El analizador lee líneas de números, ignora las líneas vacías, suma los valores analizados correctamente y escribe una línea de informe por registro procesado. ReportGenerator abre el archivo de salida por cada línea añadida. Investiga la escritura por lotes sin cambiar el análisis de datos ni el orden de salida.

Tarea 1 - Acotar e inspeccionar la carga de trabajo

1. Lee Program.cs, FileLoader.cs, DataAnalyzer.cs y ReportGenerator.cs.

2. Inspecciona el tamaño del data.txt incluido. Usa una copia pequeña para experimentar; no generes un conjunto mayor solo para obtener tiempos impresionantes.

3. Registra el directorio de trabajo y la configuración cultural. El análisis usa el formato numérico cultural actual; un cambio de cultura es un cambio de comportamiento, no una optimización de E/S.

4. Compila una vez en modo Release:

   dotnet build DataAnalyzerReporter.csproj -c Release -m:1 -p:UseSharedCompilation=false
   dotnet run --no-build -c Release --project DataAnalyzerReporter.csproj -- data.txt
   

5. Conserva el informe generado como evidencia funcional. Ejecuta únicamente en la copia desechable porque la demostración reemplaza output.txt.

Tarea 2 - Formular una hipótesis refutable

En Ask:

Inspect the loading, parsing and report-writing boundaries. Which operation is
inside the current stopwatch? Propose one bounded measurement that can compare
per-line append with a buffered writer. Do not change parsing, culture, or output.

En Plan, exige:

• la misma entrada, compilación, estado de la máquina y límite de medición;
• un calentamiento y como máximo tres ejecuciones medidas secuenciales;
• muestras de tiempo transcurrido y comparación de la salida funcional;
• ningún cambio de caché, paralelismo ni algoritmos ajenos al alcance;
• una condición de detención si la máquina está ocupada o los resultados tienen ruido.

Tarea 3 - Capturar la línea base

Registra las muestras sin procesar, sin afirmar un objetivo:

Para cargas diminutas, un temporizador de milisegundos puede indicar cero. Informa de la resolución insuficiente; no inventes una cifra más rápida ni restes un tiempo hipotético de «retraso simulado».

Tarea 4 - Implementar una optimización

1. Pide a Agent que agrupe las escrituras del informe preservando el orden y el comportamiento del análisis.
2. Inspecciona la liberación de recursos y los errores. Un escritor debe cerrarse incluso después de un fallo.
3. Vuelve a ejecutar las comprobaciones funcionales antes de medir tiempos.
4. Repite la misma medición acotada.
5. Compara las salidas y las muestras observadas. Si la salida cambia, rechaza la optimización independientemente de cualquier aceleración aparente.

Verifica tu trabajo

• El límite medido es explícito y no ha cambiado.
• Se registran la entrada, la configuración cultural, el modo de compilación y la comparación de salidas.
• Se conservan las muestras sin procesar; no se afirma ningún porcentaje universal.
• Una optimización está aislada de los cambios de análisis y reglas de negocio.
• La ejecución se mantuvo dentro del presupuesto de recursos acordado.

Solución de problemas

Las muestras con ruido pueden reflejar otros proyectos, JIT, la caché de archivos o la resolución de medición. No intentes corregir el ruido saturando la máquina. Una prueba más pequeña o un resultado no concluyente son preferibles a una medición comparativa engañosa.

Práctica independiente

En una máquina autorizada e inactiva, analiza el rendimiento de una prueba comparativa existente de ContosoOnlineStore. Registra su configuración exacta, los retrasos sintéticos, los costes de preparación y lo que excluye la medición. No deduzcas ahorros de latencia solo a partir de la complejidad asintótica.

Restablecimiento

Detén únicamente el proceso o perfilador que iniciaste. Conserva archivos pequeños de evidencia y restaura la implementación modificada en la copia desechable. Elimina solo sus informes generados.

Referencias oficiales

• Información general sobre diagnósticos de .NET
• dotnet-counters
• Stopwatch
• Buenas prácticas para agentes