Reglas de Rendimiento: Cuándo Optimizar
Reglas de medición primero y guía contra la optimización prematura.
//
Busca en todas las páginas de la documentación
Reglas de medición primero y guía contra la optimización prematura.
Úsalo cuando una PR afirme mejoras de velocidad, cuando los SLOs de latencia fallen o cuando los revisores sospechen micro-optimización prematura.
| Paso | Acción | Detener si |
|---|---|---|
| 1 | Reproducir con carga realista | No se puede reproducir - arreglar primero la observabilidad |
| 2 | go test -bench + -benchmem | El ruido domina - estabilizar el entorno |
| 3 | Perfil de CPU (pprof) | La función crítica no está en tu código - arreglar dependencias/configuración |
| 4 | Perfil de Heap/asignaciones | Las asignaciones son de inicio único - posponer trabajo |
| 5 | Traza (go tool trace) | El problema es espera de IO - ajustar timeouts/paralelismo |
| 6 | Cambio de código + delta registrado | Regresión en claridad sin ganancia de SLO |
| Señal | Palanca probable | Verificar |
|---|---|---|
| Perfil de CPU >10% en una función | Algoritmo, caché, precomputar | Perfil de CPU después |
alloc_space alto en bucle | Preasignar slice/map, strings.Builder | -benchmem |
| Fallo del SLO de pausa del GC | Reducir punteros, reutilizar buffers, heaps más pequeños | GODEBUG=gctrace=1 |
| Latencia de cola de RPC | Pooling de conexiones, batching, menos llamadas al sistema | Traza + histograma |
| Codificación JSON crítica | Reutilización de json.Encoder, estructuras más pequeñas, codegen | Benchmark de carga útil realista |
| Antipatrón | Por qué esperar | En su lugar |
|---|---|---|
| Sin perfil adjunto | Adivinar desperdicia tiempo de revisión | Hacer profiling primero |
| Micro-optimización de caminos fríos | Sin impacto en SLO | Enviar claridad |
unsafe sin ADR | Costo de seguridad y portabilidad | Prueba en Go puro |
| Pools de objetos globales en todas partes | Complejidad y estado obsoleto | Agrupar solo asignaciones probadas |
| Desactivar comprobaciones en producción | Riesgo de seguridad/fiabilidad | Corregir la causa raíz |
sync.Pool prematuro | Difícil de razonar | Medir asignaciones |
| Regla | Aplicar cuando | Omitir cuando |
|---|---|---|
| Preasignar slices | Tamaño conocido a partir de la entrada | Caminos de append raros |
strings.Builder | Muchas concatenaciones en bucle | Pocas uniones - usar + o Join |
| Pasar punteros en estructuras grandes | El perfilador muestra costo de copia | Estructuras pequeñas - preferir valores |
Reutilización de buffer json.Encoder | Codificación QPS alta | Salida CLI de un solo uso |
| PGO (optimización guiada por perfil) | Binario de carga de trabajo estable | Caminos de código que cambian rápidamente |
| Afinación de GOGC | Latencia después de correcciones de asignación | Antes de reducir las asignaciones |
go test -bench=BenchmarkFoo -benchmem -count=5 ./...
go test -cpuprofile=cpu.prof -bench=BenchmarkFoo ./...
go tool pprof -top cpu.prof| Regla | Requisito |
|---|---|
| Entrada realista | Cargas útiles del tamaño de producción |
| Reiniciar temporizador | Configuración costosa fuera del bucle |
| Comparar línea base | Rama A vs B en una PR |
| Documentar entorno | Número de CPU, versión de Go, GOMAXPROCS |
| Seguimiento ligero en CI | Opcional benchstat en etiquetas de lanzamiento |
| Área | Regla |
|---|---|
| HTTP | Establecer timeouts; reutilizar Transport con límites de conexión inactiva |
| DB | Tamaño del pool coincidente con la concurrencia; evitar consultas N+1 |
| gRPC | Reutilizar conexiones; transmitir cuando las cargas útiles son grandes |
| Concurrencia | Limitar workers; hacer profiling bajo -race por separado |
| Logging | Logs estructurados en info; debug fuera de los caminos críticos |
| Métricas | Etiquetas de baja cardinalidad |
| Perilla | Usar cuando | Precaución |
|---|---|---|
GOGC | Pausas probadas limitadas por asignaciones | Oculta fugas |
GOMEMLIMIT | Riesgo de OOM con límite claro | Puede aumentar la CPU |
| GC Green Tea (predeterminado 1.26) | Nuevos despliegues | Validar en la carga de trabajo |
debug.SetMemoryLimit | Servicios conscientes de contenedores | Probar reversión |
Al eludir una regla de claridad por velocidad, la descripción de la PR incluye:
Quema tiempo de revisión y añade errores en caminos fríos.
Optimiza cuando la medición muestre un impacto visible para el usuario.
Cuando un camino crítico está probado y el equipo documenta el compromiso con pruebas que protegen el comportamiento.
Solo PRs de rendimiento o APIs en caminos críticos.
De lo contrario, el profiling periódico es suficiente.
Puede ser trabajo en lote/fuera de pico.
Verificar histogramas de latencia de cola, no solo promedios.
Elevar la configuración, usar datos realistas, ejecutar -count=5, comparar en la misma clase de máquina.
Los informes del compilador ayudan.
Los perfiles confirman los sitios de asignación en el mundo real.
Binarios estables con perfil de CPU de producción representativo alimentado en la compilación.
Revisar cada lanzamiento.
La memoria es más limitada; la claridad sigue siendo lo primero.
Medir en objetivos de dispositivo, no solo en perfiles de escritorio.
Usar cuando el perfil de asignación muestre temporales grandes repetidos.
Reiniciar objetos en Get; nunca almacenar estado autoritativo solo en Pool.
Solo después de la reducción de asignaciones y con el límite de memoria alineado con la capacidad del contenedor.
Monitorizar la sobrecarga de CPU del GC.
Effective Go favorece la claridad.
Estas reglas añaden cuándo desviarse con evidencia.
Usar pprof en un benchmark representativo o carga de staging, siguiendo la sección de higiene de benchmarks anterior.
Versiones de Stack: Esta página fue escrita para Go 1.26.x (GC Green Tea por defecto,
go fix modernizers- verificar parche en la compilación), chi (última - verificar en la compilación), gin (última - verificar en la compilación), echo (última - verificar en la compilación), google.golang.org/grpc (última - verificar en la compilación), sigs.k8s.io/controller-runtime (última - verificar en la compilación), kubebuilder (última - verificar en la compilación), tinygo (última - verificar objetivos de placa en la compilación), wazero (última - verificar en la compilación) y golangci-lint (última - verificar conjunto de linters en la compilación).
Revisado por Chris St. John·Última actualización: 19 jul 2026