Como 4 bytes de padding em uma struct Go deixam a limpeza de arrays 49% mais rápida

O ganho de 49% na limpeza de arrays em Go não é mágica, é física de CPU em ação. Quando uma struct tem campos alinhados a múltiplos de 8 bytes, o compilador gera chamadas para REP STOSQ, instrução x86 que limpa memória em blocos de 8 bytes com otimização de 'no-read-for-ownership' (N-RFO). Se o início do array dentro da struct cai em endereço desalinhado, por exemplo, por causa da ordem dos campos, o processador Intel força leitura prévia de cada cache line antes de escrever, gerando latência extra e tráfego desnecessário no barramento L2.

Isso explica o 'padrão zebra' nos benchmarks: todo padding múltiplo de 8 restaura o alinhamento, acionando o caminho rápido. O Go garante que structs alocadas no heap sejam sempre page-aligned (4 KiB), então o desalinhamento vem só do offset interno, ou seja, da disposição dos campos. E não é só teoria: os contadores de desempenho mostraram +139% de L2 read-for-ownership em casos desalinhados. A lição prática? Em hot paths com limpeza frequente (como hash maps temporários ou buffers reutilizados), o layout de struct impacta diretamente no throughput, mais do que muitos micro-otimizações de código-fonte.

Esse tipo de otimização parece microscópico até você ter um hot path que limpa arrays de 2 MiB centenas de vezes por segundo, como em compressores (brotli), engines de jogo ou sistemas de eventos em tempo real. Aí 49% não é 'ganho de benchmark', é redução real de cycles por operação, menor pressão no cache L2 e menos estresse no memory subsystem. Além disso, revela uma armadilha silenciosa: linters de field alignment (como fieldalignment) podem piorar performance ao reordenar campos sem considerar o efeito no alinhamento do array interno. DX sofre quando o 'código bonito' quebra o caminho rápido da CPU, e ninguém avisa.