Go 1.21: Una guía para la optimización guiada por perfiles

Antes de 2023, Ir 1.20 Después de abordar las limitaciones conocidas en la previsión, y con refinamientos adicionales gracias a los comentarios y contribuciones de la comunidad, el soporte de PGO en Go 1.21 está listo para el uso general de la producción! para la documentación completa. Optimización guiada por perfiles (PGO) Guía de usuario de optimización de perfiles Vamos a analizar un ejemplo de cómo utilizar PGO para mejorar el rendimiento de una aplicación. Antes de llegar a eso, ¿qué es exactamente la “optimización guiada por perfiles”? Abajo Cuando se construye un binario Go, el compilador Go realiza optimizaciones para intentar generar el binario de mejor rendimiento que pueda. Por ejemplo, la propagación constante puede evaluar expresiones constantes en el tiempo de compilación, evitando el coste de la evaluación del tiempo de ejecución. El análisis de escape evita las asignaciones de pilas para objetos de ámbito local, evitando los encabezados de GC. Inline copia el cuerpo de funciones simples en llamadores, a menudo permitiendo una mayor optimización en el llamador (como propagación constante adicional o mejor análisis de escape). La desvirtualización convierte las llamadas indirectas en los valores de la interfaz cuyo tipo se puede determinar estatisticamente en llamadas directas al método concreto (que a menudo permite inlinear la llamada). Go mejora las optimizaciones desde el lanzamiento hasta el lanzamiento, pero no es una tarea fácil. Algunas optimizaciones son ajustables, pero el compilador no puede simplemente “devolverlo hasta 11” en cada optimización porque las optimizaciones excesivamente agresivas pueden realmente dañar el rendimiento o causar tiempos de construcción excesivos. Otras optimizaciones requieren que el compilador haga un juicio sobre cuáles son los caminos “comunes” y “inusuales” en una función. ¿O se puede? Sin información definitiva sobre cómo se utiliza el código en un entorno de producción, el compilador sólo puede operar sobre el código fuente de los paquetes. Si proporcionamos un perfil al compilador, puede tomar decisiones más informadas: optimizar más agresivamente las funciones más frecuentemente utilizadas, o seleccionar casos comunes con más precisión. El perfil El uso de perfiles de comportamiento de aplicaciones para la optimización de compiladores se conoce como (También conocido como optimización dirigida al feedback (FDO)). Optimización guiada por perfiles (PGO) Ejemplo Construyamos un servicio que convierta Markdown a HTML: los usuarios cargan la fuente de Markdown a , que devuelve la conversión HTML. Podemos usar para implementarlo fácilmente. /render gitlab.com/golang-commonmark/markdown Establecimiento $ go mod init example.com/markdown $ go get gitlab.com/golang-commonmark/markdown@bf3e522c626a en : main.go package main

import ( "bytes" "io" "log" "net/http" _ "net/http/pprof"

"gitlab.com/golang-commonmark/markdown" )

func render(w http.ResponseWriter, r *http.Request) { if r.Method != "POST" { http.Error(w, "Only POST allowed", http.StatusMethodNotAllowed) return }

src, err := io.ReadAll(r.Body) if err != nil { log.Printf("error reading body: %v", err) http.Error(w, "Internal Server Error", http.StatusInternalServerError) return }

md := markdown.New( markdown.XHTMLOutput(true), markdown.Typographer(true), markdown.Linkify(true), markdown.Tables(true), )

var buf bytes.Buffer if err := md.Render(&buf, src); err != nil { log.Printf("error converting markdown: %v", err) http.Error(w, "Malformed markdown", http.StatusBadRequest) return }

if _, err := io.Copy(w, &buf); err != nil { log.Printf("error writing response: %v", err) http.Error(w, "Internal Server Error", http.StatusInternalServerError) return } }

func main() { http.HandleFunc("/render", render) log.Printf("Serving on port 8080...") log.Fatal(http.ListenAndServe(":8080", nil)) } Crear y ejecutar el servidor: $ go build -o markdown.nopgo.exe $ ./markdown.nopgo.exe 2023/08/23 03:55:51 Serving on port 8080... Intentaremos enviar algún Markdown desde otro terminal. del proyecto Go como documento de muestra: README.md $ curl -o README.md -L "https://raw.githubusercontent.com/golang/go/c16c2c49e2fa98ae551fc6335215fadd62d33542/README.md" $ curl --data-binary @README.md http://localhost:8080/render The Go Programming Language Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.

... El perfil Ahora que tenemos un servicio de trabajo, vamos a recoger un perfil y reconstruir con PGO para ver si conseguimos un mejor rendimiento. en Nosotros importamos que se añade automáticamente a el servidor para obtener un perfil de CPU. main.go Internet / HTTP / PPROF /debug/pprof/profile Normalmente desea recopilar un perfil de su entorno de producción para que el compilador obtenga una visión representativa del comportamiento en la producción. para generar carga mientras recopilamos un perfil. Fetch y arranque el generador de carga (asegúrese de que el servidor sigue funcionando!): Programa sencillo $ go run github.com/prattmic/markdown-pgo/load@latest Mientras se ejecuta, descargue un perfil desde el servidor: $ curl -o cpu.pprof "http://localhost:8080/debug/pprof/profile?seconds=30" Una vez que esto se complete, mata el generador de carga y el servidor. Usando el perfil La cadena de herramientas de Go activará automáticamente PGO cuando encuentre un perfil llamado en el directorio principal del paquete. Alternativamente, el Bandera de toma un camino a un perfil para usar para PGO. default.pgo -pgo go build Recomendamos el compromiso El almacenamiento de perfiles junto a su código fuente garantiza que los usuarios tengan acceso automático al perfil simplemente recogiendo el repositorio (ya sea a través del sistema de control de versiones, o a través de ) y que las construcciones siguen siendo reproducibles. default.pgo go get Vamos a construir: $ mv cpu.pprof default.pgo $ go build -o markdown.withpgo.exe Podemos comprobar que PGO fue habilitado en la construcción con : go version $ go version -m markdown.withpgo.exe ./markdown.withpgo.exe: go1.21.0 ... build -pgo=/tmp/pgo121/default.pgo Evaluación Utilizaremos un benchmark para evaluar el efecto de PGO en el rendimiento. Versión del generador de carga Primero, vamos a benchmarcar el servidor sin PGO. Iniciar ese servidor: $ ./markdown.nopgo.exe Mientras esto se ejecuta, ejecute varias iteraciones de referencia: $ go get github.com/prattmic/markdown-pgo@latest $ go test github.com/prattmic/markdown-pgo/load -bench=. -count=40 -source $(pwd)/README.md > nopgo.txt Una vez que esto se complete, mata el servidor original y inicia la versión con PGO: $ ./markdown.withpgo.exe Mientras esto se ejecuta, ejecute varias iteraciones de referencia: $ go test github.com/prattmic/markdown-pgo/load -bench=. -count=40 -source $(pwd)/README.md > withpgo.txt Una vez terminado, comparemos los resultados: $ go install golang.org/x/perf/cmd/benchstat@latest $ benchstat nopgo.txt withpgo.txt goos: linux goarch: amd64 pkg: github.com/prattmic/markdown-pgo/load cpu: Intel(R) Xeon(R) W-2135 CPU @ 3.70GHz │ nopgo.txt │ withpgo.txt │ │ sec/op │ sec/op vs base │ Load-12 374.5µ ± 1% 360.2µ ± 0% -3.83% (p=0.000 n=40) La nueva versión es alrededor del 3,8% más rápida! En Go 1.21, las cargas de trabajo generalmente obtienen entre el 2% y el 7% de mejoras en el uso de la CPU de permitir PGO. Los perfiles contienen una gran cantidad de información sobre el comportamiento de la aplicación y Go 1.21 acaba de comenzar a romper la superficie usando esta información para un conjunto limitado de optimizaciones. Próximos pasos En este ejemplo, después de recoger un perfil, reconstruimos nuestro servidor utilizando exactamente el mismo código fuente utilizado en la construcción original. En un escenario del mundo real, siempre hay desarrollo en curso. Por lo tanto, podemos recoger un perfil de la producción, que está ejecutando el código de la semana pasada, y usarlo para construir con el código fuente de hoy. Eso es perfecto! PGO en Go puede manejar cambios menores al código fuente sin problema. Por supuesto, con el tiempo, el código fuente se desplazará más y más, por lo que todavía es importante actualizar el perfil ocasionalmente. Para obtener mucho más información sobre el uso de PGO, las mejores prácticas y advertencias a tener en cuenta, por favor, consulte Si estás curioso sobre lo que está sucediendo debajo del capó, ¡sigue leyendo! Guía de usuario de optimización de perfiles Bajo el hood Para obtener una mejor comprensión de lo que hizo esta aplicación más rápida, echemos un vistazo bajo el capó para ver cómo ha cambiado el rendimiento. INLINING Para observar las mejoras de enlaces, analizemos esta aplicación de marcado con y sin PGO. Compararé esto utilizando una técnica llamada perfilamiento diferencial, donde recopilamos dos perfiles (uno con PGO y uno sin) y los comparamos. , no la misma cantidad de tiempo, así que he ajustado el servidor para recopilar perfiles automáticamente, y el generador de carga para enviar un número fijo de solicitudes y luego salir del servidor. work Los cambios que he realizado al servidor así como los perfiles recopilados se pueden encontrar en El generador de carga se ejecutó con . https://github.com/prattmic/markdown-pgo -count=300000 -quit Como una rápida comprobación de la consistencia, echemos un vistazo al tiempo total de CPU necesario para manejar todas las solicitudes de 300k: $ go tool pprof -top cpu.nopgo.pprof | grep "Total samples" Duration: 116.92s, Total samples = 118.73s (101.55%) $ go tool pprof -top cpu.withpgo.pprof | grep "Total samples" Duration: 113.91s, Total samples = 115.03s (100.99%) El tiempo de la CPU bajó de ~118s a ~115s, o aproximadamente 3%. Esto está en línea con nuestros resultados de referencia, lo que es una buena señal de que estos perfiles son representativos. Ahora podemos abrir un perfil diferencial para buscar ahorros: $ go tool pprof -diff_base cpu.nopgo.pprof cpu.withpgo.pprof File: markdown.profile.withpgo.exe Type: cpu Time: Aug 28, 2023 at 10:26pm (EDT) Duration: 230.82s, Total samples = 118.73s (51.44%) Entering interactive mode (type "help" for commands, "o" for options) (pprof) top -cum Showing nodes accounting for -0.10s, 0.084% of 118.73s total Dropped 268 nodes (cum <= 0.59s) Showing top 10 nodes out of 668 flat flat% sum% cum cum% -0.03s 0.025% 0.025% -2.56s 2.16% gitlab.com/golang-commonmark/markdown.ruleLinkify 0.04s 0.034% 0.0084% -2.19s 1.84% net/http.(*conn).serve 0.02s 0.017% 0.025% -1.82s 1.53% gitlab.com/golang-commonmark/markdown.(*Markdown).Render 0.02s 0.017% 0.042% -1.80s 1.52% gitlab.com/golang-commonmark/markdown.(*Markdown).Parse -0.03s 0.025% 0.017% -1.71s 1.44% runtime.mallocgc -0.07s 0.059% 0.042% -1.62s 1.36% net/http.(*ServeMux).ServeHTTP 0.04s 0.034% 0.0084% -1.58s 1.33% net/http.serverHandler.ServeHTTP -0.01s 0.0084% 0.017% -1.57s 1.32% main.render 0.01s 0.0084% 0.0084% -1.56s 1.31% net/http.HandlerFunc.ServeHTTP -0.09s 0.076% 0.084% -1.25s 1.05% runtime.newobject (pprof) top Showing nodes accounting for -1.41s, 1.19% of 118.73s total Dropped 268 nodes (cum <= 0.59s) Showing top 10 nodes out of 668 flat flat% sum% cum cum% -0.46s 0.39% 0.39% -0.91s 0.77% runtime.scanobject -0.40s 0.34% 0.72% -0.40s 0.34% runtime.nextFreeFast (inline) 0.36s 0.3% 0.42% 0.36s 0.3% gitlab.com/golang-commonmark/markdown.performReplacements -0.35s 0.29% 0.72% -0.37s 0.31% runtime.writeHeapBits.flush 0.32s 0.27% 0.45% 0.67s 0.56% gitlab.com/golang-commonmark/markdown.ruleReplacements -0.31s 0.26% 0.71% -0.29s 0.24% runtime.writeHeapBits.write -0.30s 0.25% 0.96% -0.37s 0.31% runtime.deductAssistCredit 0.29s 0.24% 0.72% 0.10s 0.084% gitlab.com/golang-commonmark/markdown.ruleText -0.29s 0.24% 0.96% -0.29s 0.24% runtime.(*mspan).base (inline) -0.27s 0.23% 1.19% -0.42s 0.35% bytes.(*Buffer).WriteRune Cuando se especifica , los valores en mostrados en pprof son los entre los dos perfiles. por ejemplo, usó 0.46s menos tiempo de CPU con PGO que sin. En el caso de que se utilice un valor de 0.36s más tiempo de CPU. En un perfil diferencial, por lo general queremos mirar los valores absolutos ( y porcentajes, ya que los porcentajes no son significativos. pprof -diff_base Diferencias runtime.scanobject gitlab.com/golang-commonmark/markdown.performReplacements flat cum muestra las principales diferencias por cambio acumulativo. Es decir, la diferencia en la CPU de una función y todas las calles transitivas de esa función. Esto generalmente mostrará los marcos más externos en el gráfico de llamadas de nuestro programa, tales como: o otro punto de entrada goroutine. Aquí podemos ver que la mayoría de los ahorros vienen del Tratamiento de solicitudes HTTP. top -cum main ruleLinkify muestra las principales diferencias limitadas sólo a los cambios en la función misma. Esto generalmente mostrará los marcos internos en el gráfico de llamadas de nuestro programa, donde está ocurriendo la mayor parte del trabajo real. las funciones. top runtime Vamos a mirar la pila de llamadas para ver de dónde vienen: (pprof) peek scanobject$ Showing nodes accounting for -3.72s, 3.13% of 118.73s total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- -0.86s 94.51% | runtime.gcDrain -0.09s 9.89% | runtime.gcDrainN 0.04s 4.40% | runtime.markrootSpans -0.46s 0.39% 0.39% -0.91s 0.77% | runtime.scanobject -0.19s 20.88% | runtime.greyobject -0.13s 14.29% | runtime.heapBits.nextFast (inline) -0.08s 8.79% | runtime.heapBits.next -0.08s 8.79% | runtime.spanOfUnchecked (inline) 0.04s 4.40% | runtime.heapBitsForAddr -0.01s 1.10% | runtime.findObject ----------------------------------------------------------+------------- (pprof) peek gcDrain$ Showing nodes accounting for -3.72s, 3.13% of 118.73s total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- -1s 100% | runtime.gcBgMarkWorker.func2 0.15s 0.13% 0.13% -1s 0.84% | runtime.gcDrain -0.86s 86.00% | runtime.scanobject -0.18s 18.00% | runtime.(*gcWork).balance -0.11s 11.00% | runtime.(*gcWork).tryGet 0.09s 9.00% | runtime.pollWork -0.03s 3.00% | runtime.(*gcWork).tryGetFast (inline) -0.03s 3.00% | runtime.markroot -0.02s 2.00% | runtime.wbBufFlush 0.01s 1.00% | runtime/internal/atomic.(*Bool).Load (inline) -0.01s 1.00% | runtime.gcFlushBgCredit -0.01s 1.00% | runtime/internal/atomic.(*Int64).Add (inline) ----------------------------------------------------------+------------- así En última instancia, viene de • El Nos dice que es parte del colector de basura, así Los ahorros deben ser GC ahorros. y otro de funciones? runtime.scanobject runtime.gcBgMarkWorker Guía GC runtime.gcBgMarkWorker runtime.scanobject nextFreeFast runtime (pprof) peek nextFreeFast$ Showing nodes accounting for -3.72s, 3.13% of 118.73s total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- -0.40s 100% | runtime.mallocgc (inline) -0.40s 0.34% 0.34% -0.40s 0.34% | runtime.nextFreeFast ----------------------------------------------------------+------------- (pprof) peek writeHeapBits Showing nodes accounting for -3.72s, 3.13% of 118.73s total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- -0.37s 100% | runtime.heapBitsSetType 0 0% | runtime.(*mspan).initHeapBits -0.35s 0.29% 0.29% -0.37s 0.31% | runtime.writeHeapBits.flush -0.02s 5.41% | runtime.arenaIndex (inline) ----------------------------------------------------------+------------- -0.29s 100% | runtime.heapBitsSetType -0.31s 0.26% 0.56% -0.29s 0.24% | runtime.writeHeapBits.write 0.02s 6.90% | runtime.arenaIndex (inline) ----------------------------------------------------------+------------- (pprof) peek heapBitsSetType$ Showing nodes accounting for -3.72s, 3.13% of 118.73s total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- -0.82s 100% | runtime.mallocgc -0.12s 0.1% 0.1% -0.82s 0.69% | runtime.heapBitsSetType -0.37s 45.12% | runtime.writeHeapBits.flush -0.29s 35.37% | runtime.writeHeapBits.write -0.03s 3.66% | runtime.readUintptr (inline) -0.01s 1.22% | runtime.writeHeapBitsForAddr (inline) ----------------------------------------------------------+------------- (pprof) peek deductAssistCredit$ Showing nodes accounting for -3.72s, 3.13% of 118.73s total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- -0.37s 100% | runtime.mallocgc -0.30s 0.25% 0.25% -0.37s 0.31% | runtime.deductAssistCredit -0.07s 18.92% | runtime.gcAssistAlloc ----------------------------------------------------------+------------- Parece como y algunos de los otros en el top 10 finalmente vienen de , que la Guía GC nos dice es el alocador de memoria. nextFreeFast runtime.mallocgc Los costos reducidos en el GC y el alocador implican que estamos asignando menos en general. $ go tool pprof -sample_index=alloc_objects -diff_base heap.nopgo.pprof heap.withpgo.pprof File: markdown.profile.withpgo.exe Type: alloc_objects Time: Aug 28, 2023 at 10:28pm (EDT) Entering interactive mode (type "help" for commands, "o" for options) (pprof) top Showing nodes accounting for -12044903, 8.29% of 145309950 total Dropped 60 nodes (cum <= 726549) Showing top 10 nodes out of 58 flat flat% sum% cum cum% -4974135 3.42% 3.42% -4974135 3.42% gitlab.com/golang-commonmark/mdurl.Parse -4249044 2.92% 6.35% -4249044 2.92% gitlab.com/golang-commonmark/mdurl.(*URL).String -901135 0.62% 6.97% -977596 0.67% gitlab.com/golang-commonmark/puny.mapLabels -653998 0.45% 7.42% -482491 0.33% gitlab.com/golang-commonmark/markdown.(*StateInline).PushPending -557073 0.38% 7.80% -557073 0.38% gitlab.com/golang-commonmark/linkify.Links -557073 0.38% 8.18% -557073 0.38% strings.genSplit -436919 0.3% 8.48% -232152 0.16% gitlab.com/golang-commonmark/markdown.(*StateBlock).Lines -408617 0.28% 8.77% -408617 0.28% net/textproto.readMIMEHeader 401432 0.28% 8.49% 499610 0.34% bytes.(*Buffer).grow 291659 0.2% 8.29% 291659 0.2% bytes.(*Buffer).String (inline) El la opción nos muestra el número de asignaciones, independientemente del tamaño. Esto es útil ya que estamos investigando una disminución en el uso de la CPU, que tiende a correlacionar más con el número de asignaciones en lugar del tamaño. . -sample_index=alloc_objects mdurl.Parse Para referencia, echemos un vistazo a las cuentas totales de asignación para esta función sin PGO: $ go tool pprof -sample_index=alloc_objects -top heap.nopgo.pprof | grep mdurl.Parse 4974135 3.42% 68.60% 4974135 3.42% gitlab.com/golang-commonmark/mdurl.Parse El número total antes era 4974135, lo que significa que ¡Ha eliminado el 100% de las asignaciones! mdurl.Parse Volviendo al perfil diferencial, recopilemos un poco más de contexto: (pprof) peek mdurl.Parse Showing nodes accounting for -12257184, 8.44% of 145309950 total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- -2956806 59.44% | gitlab.com/golang-commonmark/markdown.normalizeLink -2017329 40.56% | gitlab.com/golang-commonmark/markdown.normalizeLinkText -4974135 3.42% 3.42% -4974135 3.42% | gitlab.com/golang-commonmark/mdurl.Parse ----------------------------------------------------------+------------- Las llamadas a vienen de y . mdurl.Parse markdown.normalizeLink markdown.normalizeLinkText (pprof) list mdurl.Parse Total: 145309950 ROUTINE ======================== gitlab.com/golang-commonmark/mdurl.Parse in /usr/local/google/home/mpratt/go/pkg/mod/gitlab.com/golang-commonmark/mdurl@v0.0.0-20191124015652-932350d1cb84/parse .go -4974135 -4974135 (flat, cum) 3.42% of Total . . 60:func Parse(rawurl string) (*URL, error) { . . 61: n, err := findScheme(rawurl) . . 62: if err != nil { . . 63: return nil, err . . 64: } . . 65: -4974135 -4974135 66: var url URL . . 67: rest := rawurl . . 68: hostless := false . . 69: if n > 0 { . . 70: url.RawScheme = rest[:n] . . 71: url.Scheme, rest = strings.ToLower(rest[:n]), rest[n+1:] La fuente completa para estas funciones y llamadores se puede encontrar en: Página principal.Parse Markdown.normalizeLink Markdown.normalizeLinkText ¿Qué ocurrió aquí? en una construcción no-PGO, No obstante, porque nuestro perfil PGO indicaba que las llamadas a esta función eran calientes, el compilador las inlineó. Podemos ver esto desde la anotación “(inline)” en los perfiles: mdurl.Parse $ go tool pprof -top cpu.nopgo.pprof | grep mdurl.Parse 0.36s 0.3% 63.76% 2.75s 2.32% gitlab.com/golang-commonmark/mdurl.Parse $ go tool pprof -top cpu.withpgo.pprof | grep mdurl.Parse 0.55s 0.48% 58.12% 2.03s 1.76% gitlab.com/golang-commonmark/mdurl.Parse (inline) Creación a como una variable local en la línea 66 ( ), y luego devuelve un puntero a esa variable en la línea 145 ( Normalmente esto requiere que la variable sea asignada a la pila, como referencia a que vive más allá del retorno de la función. Está insertado en , el compilador puede observar que la variable no escapa , que permite al compilador asignarlo a la pila. Es similar a . mdurl.Parse URL var url URL return &url, nil mdurl.Parse markdown.normalizeLink normalizeLink markdown.normalizeLinkText markdown.normalizeLink La segunda mayor reducción mostrada en el perfil, de es un caso similar de eliminar una fuga después de inlinear. mdurl.(*URL).String En estos casos, obtuvimos un mejor rendimiento a través de menos asignaciones de pilas. Parte del poder de las optimizaciones de PGO y compiladores en general es que los efectos sobre las asignaciones no son parte de la implementación de PGO del compilador en absoluto. Todos los efectos para el análisis de escape y la asignación de pila fueron optimizaciones estándar que se aplican a cualquier construcción. El comportamiento de escape mejorado es un gran efecto descendente del inlining, pero no es el único efecto. Muchas optimizaciones pueden aprovechar el inlining. Por ejemplo, la propagación constante puede ser capaz de simplificar el código en una función después del inlining cuando algunas de las entradas son constantes. Desvirtualización Además del inling, que vimos en el ejemplo anterior, PGO también puede impulsar la desvirtualización condicional de las llamadas de interfaz. Antes de entrar en la desvirtualización impulsada por PGO, vamos a dar un paso atrás y definir "desvirtualización" en general.Supongamos que usted tiene código que se ve como algo así: f, _ := os.Open("foo.txt") var r io.Reader = f r.Read(b) Aquí tenemos una llamada a la Método de Interfaz Dado que las interfaces pueden tener múltiples implementaciones, el compilador genera una llamada de función, lo que significa que busca el método correcto para llamar en el tiempo de ejecución desde el tipo en el valor de la interfaz. Las llamadas indirectas tienen un pequeño coste adicional de tiempo de ejecución en comparación con las llamadas directas, pero lo más importante es que excluyen algunas optimizaciones del compilador. io.Reader Read indirectamente En el ejemplo anterior, nos Conocer el procedimiento correcto, debe ser Desde que es el único tipo que podría ser asignado a En este caso, el compilador realizará , donde sustituye la llamada indirecta a Con una llamada directa a permitiendo otras optimizaciones. por os.(*File).Read *os.File r Desvirtualización io.Reader.Read os.(*File).Read (Probablemente estés pensando: "Este código es inútil, ¿por qué alguien lo escribió de esa manera?"Este es un buen punto, pero tenga en cuenta que el código como el de arriba podría ser el resultado de la incorporación. Se trata de una función que toma un Una vez que la función está enmarcada, ahora la se hace más concreta.) f io.Reader io.Reader La desvirtualización impulsada por PGO extiende este concepto a situaciones en las que el tipo de hormigón no es estatisticamente conocido, pero el perfilado puede demostrar que, por ejemplo, un Llamar a los objetivos la mayor parte del tiempo. En este caso, el PGO puede reemplazar Con algo como: io.Reader.Read os.(*File).Read r.Read(b) if f, ok := r.(*os.File); ok { f.Read(b) } else { r.Read(b) } Es decir, añadimos un control de tiempo de ejecución para el tipo de hormigón que es más probable que aparezca, y si es así, utilice una llamada de hormigón, o de otro modo vuelva a la llamada indirecta estándar. ) puede ser enmarcada y tener optimizaciones adicionales aplicadas, pero todavía mantenemos un camino de retroceso porque un perfil no es una garantía de que esto siempre será el caso. *os.File En nuestro análisis del servidor de marcado no vimos desvirtualización impulsada por PGO, pero también sólo miramos las áreas más afectadas. PGO (y la mayoría de las optimizaciones de compiladores) generalmente dan su beneficio en el conjunto de mejoras muy pequeñas en muchos lugares diferentes, por lo que es probable que haya más que lo que miramos. Inlining y desvirtualization son las dos optimizaciones basadas en PGO disponibles en Go 1.21, pero como hemos visto, estas a menudo desbloquean optimizaciones adicionales. Reconocimientos La adición de la optimización guiada por perfiles a Go ha sido un esfuerzo de equipo, y sin duda quiero destacar las contribuciones de Raj Barik y Jin Lin en Uber, y Cherry Mui y Austin Clements en Google. por Michael Pratt Este artículo está disponible en The Go Blog bajo una licencia CC BY 4.0 DEED. El blog de Go El blog de Go Fotografía de Ben Sweet en Unsplash El dulce Unosplash