Go 1.21: Průvodce profilovou optimalizací

Dříve v roce 2023, Go 1.20 Po vyřešení známých omezení v náhledu a s dalšími vylepšeními díky zpětné vazbě a příspěvkům komunity je podpora PGO v Go 1.21 připravena pro obecné použití ve výrobě! Pro kompletní dokumentaci. Využití optimalizace vedené profilem (Profil-Guided Optimization – PGO) Profilová optimalizace uživatelská příručka Projdeme si příkladem používání PGO ke zlepšení výkonu aplikace.Předtím, než se k tomu dostaneme, co přesně je „optimalizace vedená profilem“? Níže Když vytvoříte Go binární, kompilátor Go provádí optimalizace, aby se pokusil vytvořit nejlepší výkonný binární, jaký může. Například konstantní propagace může vyhodnotit konstantní výrazy v čase kompilace, čímž se zabrání nákladům na vyhodnocení běhu. Analýza útěku zabraňuje hromadnému přidělování pro lokálně rozsáhlé objekty, čímž se zabrání GC overheads. Inlining kopíruje tělo jednoduchých funkcí do volajících, což často umožňuje další optimalizaci v volání (jako je další konstantní propagace nebo lepší analýza útěku). Devirtualizace převádí nepřímé hovory na hodnotách rozhraní, jejichž typ lze určit staticky do přímých hovorů na konkrétní metodu (co Některé optimalizace jsou nastavitelné, ale kompilátor nemůže na každé optimalizaci „převést až na 11“, protože nadměrně agresivní optimalizace mohou ve skutečnosti poškodit výkon nebo způsobit nadměrné časy budování. Jiné optimalizace vyžadují, aby kompilátor učinil úsudek o tom, jaké jsou „běžné“ a „neobvyklé“ cesty ve funkci. kompilátor musí udělat nejlepší odhad na základě statické heuristiky, protože nemůže vědět, které případy budou běžné v době spuštění. Nebo to může? Bez definitivních informací o tom, jak se kód používá ve výrobním prostředí, může kompilátor pracovat pouze na zdrojovém kódu balíčků. Pokud kompilátorovi poskytneme profil, může činit informovanější rozhodnutí: agresivněji optimalizovat nejčastěji používané funkce nebo přesněji vybírat běžné případy. Profilování Použití profilů chování aplikací pro optimalizaci kompilátoru je známo jako (také známý jako zpětná vazba-orientované optimalizace (FDO) Optimalizace vedená profilem (PGO) Příklad Pojďme vytvořit službu, která převede Markdown na HTML: uživatelé nahrají zdroj Markdown na , který vrací konverzi HTML. Můžeme použít Pro snadnou implementaci. /render gitlab.com/golang-commonmark/markdown Set up $ go mod init example.com/markdown $ go get gitlab.com/golang-commonmark/markdown@bf3e522c626a v : 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)) } Vytvoření a spuštění serveru: $ go build -o markdown.nopgo.exe $ ./markdown.nopgo.exe 2023/08/23 03:55:51 Serving on port 8080... Zkusme poslat nějaký Markdown z jiného terminálu. z projektu Go jako vzorového dokumentu: 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.

... Profilování Nyní, když máme pracovní službu, pojďme shromáždit profil a přestavět s PGO, abychom zjistili, zda máme lepší výkon. v importovali jsme automaticky přidává a Konec koncového serveru pro získání profilu CPU. main.go Internetové stránky / HTTP / PPProf /debug/pprof/profile Obvykle chcete shromáždit profil z vašeho výrobního prostředí, aby kompilátor získal reprezentativní pohled na chování ve výrobě. vytvářet zatížení, zatímco shromažďujeme profil. Fetch a spustit generátor zatížení (Ujistěte se, že server stále běží!): Jednoduchý program $ go run github.com/prattmic/markdown-pgo/load@latest Zatímco to běží, stáhněte si profil ze serveru: $ curl -o cpu.pprof "http://localhost:8080/debug/pprof/profile?seconds=30" Jakmile to dokončíte, zabijte generátor zatížení a server. Použití profilu Řetězec nástrojů Go automaticky aktivuje PGO, když najde profil s názvem v hlavním adresáři balíčku. Alternativně Vlajka 2 vyžaduje cestu k profilu pro použití pro PGO. default.pgo -pgo go build Doporučujeme se zavázat Ukládání profilů vedle zdrojového kódu zajišťuje, že uživatelé mají automaticky přístup k profilu jednoduše vyzvednutím úložiště (buď prostřednictvím systému řízení verzí, nebo prostřednictvím a tyto stavby zůstávají reprodukovatelné. default.pgo go get Pojďme si stavět: $ mv cpu.pprof default.pgo $ go build -o markdown.withpgo.exe Můžeme zkontrolovat, zda bylo PGO aktivováno ve stavbě s : go version $ go version -m markdown.withpgo.exe ./markdown.withpgo.exe: go1.21.0 ... build -pgo=/tmp/pgo121/default.pgo Hodnocení Budeme používat Go benchmark posoudit vliv PGO na výkonnost. Verze generátoru zatížení Nejprve porovnáme server bez PGO. $ ./markdown.nopgo.exe Zatímco to běží, spusťte několik iterací referenčních bodů: $ 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 Jakmile to dokončíte, zabijte původní server a spusťte verzi s PGO: $ ./markdown.withpgo.exe Zatímco to běží, spusťte několik iterací referenčních bodů: $ go test github.com/prattmic/markdown-pgo/load -bench=. -count=40 -source $(pwd)/README.md > withpgo.txt Jakmile se to podaří, porovnejme výsledky: $ 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) Nová verze je přibližně o 3,8 % rychlejší! V Go 1.21, pracovní zatížení obvykle získat mezi 2% a 7% zlepšení využití CPU z umožnění PGO. Profily obsahují spoustu informací o chování aplikací a Go 1.21 právě začíná prasknout povrch tím, že používá tyto informace pro omezený soubor optimalizací. budoucí vydání budou i nadále zlepšovat výkon, protože více částí kompilátoru využít PGO. Další kroky V tomto příkladu, po shromáždění profilu, jsme přestavili náš server pomocí přesně stejného zdrojového kódu použitého v původním buildu. V reálném světě scénář, tam je vždy probíhající vývoj. Takže můžeme shromažďovat profil z výroby, který běží minulý týden kód, a použít jej k budování s dnešním zdrojovým kódem. To je naprosto v pořádku! PGO v Go může zvládnout drobné změny na zdrojový kód bez problémů. Samozřejmě, v průběhu času zdrojový kód bude drift více a více, takže je stále důležité aktualizovat profil příležitostně. Pro mnohem více informací o používání PGO, osvědčených postupů a varování, prosím, podívejte se na Pokud jste zvědaví, co se děje pod kapotou, pokračujte v čtení! Profilová optimalizace uživatelská příručka Pod kapotou Abychom lépe porozuměli tomu, co tuto aplikaci urychlilo, podívejme se pod kapotu a uvidíme, jak se výkon změnil. Inlinování Chcete-li pozorovat zlepšení inliningu, analyzujme tuto aplikaci s označením a bez PGO. Porovnám to pomocí techniky zvané diferenciální profilování, kde shromažďujeme dva profily (jeden s PGO a jeden bez) a porovnáme je. , ne stejné množství času, takže jsem nastavil server automaticky shromažďovat profily, a generátor zatížení odeslat pevný počet požadavků a pak opustit server. work Změny, které jsem provedl na serveru, jakož i shromážděné profily lze nalézt na Generátor byl spuštěn s . https://github.com/prattmic/markdown-pgo -count=300000 -quit Pro rychlou kontrolu konzistence se podívejme na celkový čas procesoru potřebný pro zpracování všech 300 000 žádostí: $ 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%) Čas procesoru klesl z ~118s na ~115s, nebo přibližně 3%.To je v souladu s našimi referenčními výsledky, což je dobré znamení, že tyto profily jsou reprezentativní. Nyní můžeme otevřít diferenciální profil, abychom hledali úspory: $ 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 Při specifikování , hodnoty zobrazené v pprof jsou mezi těmito dvěma profily. používá 0,46s méně času CPU s PGO než bez. V tomto případě je nutné mít na paměti, že v případě, že se jedná o rozdíl v rozmezí, je nutné vzít v úvahu, že se jedná o rozdíl v rozmezí ( a Procentuální hodnoty (procentuální hodnoty) nemají žádný význam. pprof -diff_base Rozdíl runtime.scanobject gitlab.com/golang-commonmark/markdown.performReplacements flat cum zobrazuje hlavní rozdíly podle kumulativní změny. tj. rozdíl v CPU funkce a všech přechodných ulicích od této funkce. Toto bude obecně zobrazovat nejvnější rámy v grafu volání našeho programu, jako jsou: nebo jiný goroutine vstupní bod. Zde můžeme vidět, že většina úspor pochází z Řešení HTTP požadavků. top -cum main ruleLinkify ukazuje hlavní rozdíly omezené pouze na změny v samotné funkci. To všeobecně ukáže vnitřní rámce v grafu volání našeho programu, kde se odehrává většina skutečné práce. a funkcí. top runtime Pojďme se podívat na stack volání, abychom zjistili, odkud pocházejí: (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) ----------------------------------------------------------+------------- tak Konečně pochází z • The Řekněte nám, že je součástí sběrače odpadků, takže Ušetřené peníze by měly být ušetřené.cz a další A funkce ? runtime.scanobject runtime.gcBgMarkWorker Go GC průvodce 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 ----------------------------------------------------------+------------- Vypadá jako Některé z prvních deseti se nakonec dostaly do , který nám GC Guide říká, je alokátor paměti. nextFreeFast runtime.mallocgc Snížené náklady v GC a alokátoru znamenají, že přidělujeme méně celkově. $ 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) Tyto Tato možnost nám ukazuje počet alokací, bez ohledu na velikost. To je užitečné, protože zkoumáme pokles využití CPU, který má tendenci více korelovat s počtem alokací než s velikostí. . -sample_index=alloc_objects mdurl.Parse Pro referenci se podívejme na celkové počty přidělení pro tuto funkci bez 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 Celkový počet předtím byl 4974135, což znamená, že Odstranili jsme 100 % příspěvků! mdurl.Parse Zpět do diferenciálního profilu, pojďme shromáždit trochu více kontextu: (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 ----------------------------------------------------------+------------- Volání na Přicházejí z a . 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:] Kompletní zdroj pro tyto funkce a volající lze nalézt na: Štítek: Parse Markdown.normalizaceLink Markdown.normalizovatLinkText Co se tedy děje? v ne-PGO budování, je považován za příliš velký na to, aby byl způsobilý pro inline. Avšak protože náš profil PGO naznačoval, že volání k této funkci bylo horké, kompilátor je inline. 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) Vytvořte A jako místní proměnná na řádku 66 ( ), a poté vrátí ukazatel k této proměnné na řádku 145 ( Obvykle to vyžaduje, aby byla proměnná přidělena na hromadu, jako odkaz na to, že žije mimo funkční návrat. Je vkládán do , kompilátor může pozorovat, že proměnná neunikne , což umožňuje kompilátoru přidělit ji na hromadu. Je podobný . mdurl.Parse URL var url URL return &url, nil mdurl.Parse markdown.normalizeLink normalizeLink markdown.normalizeLinkText markdown.normalizeLink Druhý největší snížení uvedené v profilu, od Je to podobný případ odstranění útěku po vkládání. mdurl.(*URL).String Část síly PGO a optimalizací kompilátoru obecně spočívá v tom, že účinky na alokace nejsou součástí implementace PGO kompilátoru vůbec. Všechny účinky na analýzu útěku a přidělení hromady byly standardními optimalizacemi, které se vztahují na jakoukoli stavbu. Zlepšené chování útěku je velkým následným efektem inliningu, ale není to jediný efekt. Mnoho optimalizací může využít inliningu. Například konstantní propagace může být schopna zjednodušit kód ve funkci po inliningu, když jsou některé vstupy konstantní. Devirtualizace Kromě inlingu, který jsme viděli v příkladu výše, může PGO také pohánět podmíněnou devirtualizace hovorů rozhraní. Předtím, než se dostaneme k PGO-poháněné devirtualizace, pojďme krok zpět a definovat „devirtualizace“ obecně. f, _ := os.Open("foo.txt") var r io.Reader = f r.Read(b) Zde je výzva pro Interiérová metoda Vzhledem k tomu, že rozhraní může mít více implementací, kompilátor generuje funkční volání, což znamená, že vyhledává správnou metodu volání v době spuštění z typu v hodnotě rozhraní. Nepřímé volání mají malou dodatečnou náklady na dobu spuštění ve srovnání s přímými voláními, ale důležitější je, že vylučují některé optimalizace kompilátoru. io.Reader Read Nepřímé V příkladu uvedeném výše jsme Využijte praktické metody, musí to být Od té doby je jediným typem, který by mohl být přidělen V tomto případě kompilátor provede , kde nahrazuje nepřímý hovor na Při přímém volání na Tímto způsobem umožňují další optimalizace. do os.(*File).Read *os.File r Devirtualizace io.Reader.Read os.(*File).Read (Pravděpodobně si myslíte, že „tento kód je zbytečný, proč by to někdo napsal tímto způsobem?“ To je dobrý bod, ale mějte na paměti, že kód jako výše by mohl být výsledkem vkládání. přechází do funkce, která má argument. Jakmile je funkce inlinována, nyní To se stává konkrétním.) f io.Reader io.Reader Devirtualizace řízená PGO rozšiřuje tento koncept na situace, kdy konkrétní typ není staticky znám, ale profilování může ukázat, že například Zavolejte cíle většinu času. V tomto případě může PGO nahradit s něčím jako: io.Reader.Read os.(*File).Read r.Read(b) if f, ok := r.(*os.File); ok { f.Read(b) } else { r.Read(b) } To znamená, že přidáváme kontrolu běhu pro konkrétní typ, který je pravděpodobnější, že se objeví, a pokud ano, použijte konkrétní volání, nebo se jinak vrátíte ke standardnímu nepřímému volání. ) mohou být upřesněny a aplikovány další optimalizace, ale stále udržujeme zpětnou cestu, protože profil není zárukou, že to tak bude vždycky. *os.File PGO (a většina optimalizací kompilátorů) obecně přinášejí svůj prospěch v souhrnu velmi malých zlepšení na mnoha různých místech, takže je pravděpodobné, že se stane více než jen to, co jsme se podívali. Inlining a devirtualizace jsou dvě optimalizace založené na PGO dostupné v Go 1.21, ale jak jsme viděli, tyto často odemykávají další optimalizace. uznání Přidání optimalizace založené na profilu do Go bylo týmovým úsilím a určitě chci upozornit na příspěvky Raj Barika a Jin Lin z Uberu a Cherry Mui a Austin Clements z Google. Michael Prattová Tento článek je k dispozici na The Go Blog pod licencí CC BY 4.0 DEED. Blog Go Blog Go Obrázek: Ben Sweet na Unsplash Ben Sladký Unsplashová