Analise o desempenho de uma carga delimitada com o GitHub Copilot

Um agente pode sugerir um gargalo. Somente uma medição pode mostrar o que aconteceu na sua carga de trabalho. Um resultado válido pode ser nenhuma melhoria mensurável.

Resumo do laboratório

[!NOTE] Um resultado inconclusivo é melhor do que um tempo fabricado.

Conceitos · Primeira tarefa · Lista de evidências · Redefinir

Objetivos de aprendizagem

• Defina um limite de medição antes de otimizar.
• Preserve a saída funcional ao comparar uma única alteração.
• Diferencie tempo decorrido, alocações, memória retida e pico de memória.
• Evite testes de carga, concorrência sem limites e grandes conjuntos de dados em uma máquina compartilhada.

Antes de começar

Prepare 10-profiling com a configuração de recursos limitados. A fixture padrão é o pequeno DataAnalyzerReporter. Os exemplos importados de ContosoOnlineStore e benchmarks são uma extensão opcional para máquina isolada, não parte da execução padrão. Não inicie BenchmarkDotNet, um teste de carga ou uma distribuição paralela de solicitações aqui.

Conceitos e casos de uso

A demonstração atual inicia o cronômetro depois de carregar a entrada. Portanto, a duração impressa não mede o carregamento de arquivos. Explique essa limitação antes de alterar FileLoader.

Cenário do exercício

O analisador lê linhas de números, ignora linhas em branco, soma valores analisados com sucesso e grava uma linha de relatório por registro processado. ReportGenerator abre o arquivo de saída a cada linha acrescentada. Investigue a gravação em lote sem alterar a análise dos dados nem a ordem da saída.

Tarefa 1 - Delimite e inspecione a carga de trabalho

1. Leia Program.cs, FileLoader.cs, DataAnalyzer.cs e ReportGenerator.cs.

2. Inspecione o tamanho do data.txt incluído. Use uma cópia pequena para experimentar; não gere um conjunto de dados maior apenas para obter tempos impressionantes.

3. Registre o diretório de trabalho e a cultura. A análise usa a cultura numérica atual; uma mudança de cultura é uma mudança de comportamento, não uma otimização de E/S.

4. Compile uma vez no 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. Mantenha o relatório gerado como evidência funcional. Execute somente na cópia descartável porque a demonstração substitui output.txt.

Tarefa 2 - Declare uma hipótese refutável

Em 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.

Em Plan, exija:

• a mesma entrada, compilação, estado da máquina e limite de medição;
• um aquecimento e no máximo três execuções medidas sequenciais;
• amostras de tempo decorrido e comparação da saída funcional;
• nenhum cache, paralelismo ou alteração de algoritmo sem relação com a tarefa;
• uma condição de parada se a máquina estiver ocupada ou os resultados apresentarem ruído.

Tarefa 3 - Capture a linha de base

Registre amostras brutas sem alegar uma meta:

Para cargas minúsculas, um temporizador em milissegundos pode informar zero. Relate a resolução inadequada; não invente um número mais rápido nem subtraia um tempo hipotético de “atraso simulado”.

Tarefa 4 - Implemente uma otimização

1. Peça a Agent que agrupe as gravações do relatório em lote, preservando a ordem e o comportamento da análise.
2. Inspecione a liberação de recursos e os erros. Um gravador deve ser fechado mesmo após uma falha.
3. Execute novamente as verificações funcionais antes de medir o tempo.
4. Repita a mesma medição delimitada.
5. Compare as saídas e as amostras observadas. Se a saída mudar, rejeite a otimização, independentemente de qualquer ganho aparente de velocidade.

Verifique seu trabalho

• O limite medido é explícito e permanece inalterado.
• Entrada, cultura, modo de compilação e comparação de saída estão registrados.
• As amostras brutas são mantidas; nenhuma porcentagem universal é alegada.
• Uma otimização está isolada de alterações na análise e nas regras de negócio.
• A execução permaneceu dentro do orçamento de recursos acordado.

Solução de problemas

Amostras ruidosas podem refletir outros projetos, JIT, cache de arquivos ou resolução da medição. Não tente corrigir o ruído saturando a máquina. Um teste menor ou um resultado inconclusivo é preferível a um benchmark enganoso.

Prática independente

Em uma máquina ociosa autorizada, analise o desempenho de um benchmark existente de ContosoOnlineStore. Registre sua configuração exata, atrasos sintéticos, custos de preparação e o que o benchmark exclui. Não deduza economias de latência apenas da complexidade assintótica.

Restauração

Pare somente o processo/profiler que você iniciou. Preserve pequenos arquivos de evidências e restaure a implementação alterada na cópia descartável. Remova somente os relatórios gerados por ela.

Referências oficiais

• Visão geral de diagnósticos do .NET
• dotnet-counters
• Stopwatch
• Boas práticas para agentes