Cum să storci ultimul drop de performanță din codul Go limitat de CPU

Optimizarea codului limitat de CPU e ca și cum ai încerca să câștigi o cursă de Formula 1 când ai doar o bicicletă. Dar dacă bicicleta e scrisă în Go, ai șanse. Într-o notă recentă, un inginer Google (cine altcineva?) a analizat cazuri reale de accelerare a hot paths — acele porțiuni de cod unde performanța scade.

Ce găsești înăuntru?

Autorul nu recită documentația, ci arată cu exemple cum profilarea cu pprof și utilizarea corectă a benchmark-urilor ajută la găsirea blocajelor. Surpriză: de multe ori problema nu e în algoritm, ci în faptul că compilatorul nu ghicește optimizări evidente pentru dezvoltator. De exemplu, alocări inutile în bucle sau lucrul ineficient cu interfețe.

Câteva trucuri pe care le-am remarcat:

• Folosește sync.Pool pentru obiecte create frecvent și cu viață scurtă — e ca vesela reutilizabilă la picnic, dar pentru gorutine.
• Uneori merită să înlocuiești un map cu un slice și căutare binară, dacă cheile nu sunt un milion și accesul e doar citire. Da, nu e la fel de elegant, dar e mai rapid.
• Și cel mai important — nu optimiza orbește. Profilează, profilează și iar profilează. Altfel riști să pierzi o săptămână accelerând ceva ce deja mergea bine.

Comentariul echipei METABYTE: Și la METABYTE avem hot paths — de exemplu, codul care procesează comenzile clienților. Dacă nu am urmări performanța, ar trebui să explicăm clientului de ce site-ul lui merge încet. Noi preferăm să explicăm de ce zboară. Așa că profilarea e totul pentru noi, dar fără fanatism.