Difu rindu veiktspēja: GitHub sarežģītais ceļš uz optimizāciju

GitHub sarežģītais ceļš: Difu rindu optimizēšana maksimālai veiktspējai

Izmaiņu pieprasījumi veido GitHub spilgto kodolu, kur neskaitāmi inženieri velta ievērojamu daļu savas profesionālās dzīves. Ņemot vērā GitHub milzīgo mērogu, apstrādājot izmaiņu pieprasījumus, kas svārstās no nelieliem vienas rindas labojumiem līdz milzīgiem grozījumiem, kas aptver tūkstošiem failu un miljoniem rindu, pārskatīšanas pieredzei ir jāpaliek ārkārtīgi ātrai un atsaucīgai. Nesenā jaunās uz React balstītās pieredzes ieviešana cilnei Mainītie faili, kas tagad ir noklusējuma visiem lietotājiem, iezīmēja būtisku ieguldījumu stabilas veiktspējas nodrošināšanā, īpaši šiem sarežģītajiem lielajiem izmaiņu pieprasījumiem. Šī apņemšanās ietvēra pastāvīgu grūtu problēmu risināšanu, piemēram, optimizētu renderēšanu, mijiedarbības latentumu un atmiņas patēriņu.

Pirms šīm optimizācijām, lai gan lielākā daļa lietotāju baudīja atsaucīgu pieredzi, lieli izmaiņu pieprasījumi neizbēgami izraisīja pamanāmu veiktspējas samazināšanos. Ekstrēmos gadījumos JavaScript atmiņas apgabals pārsniedza 1 GB, DOM mezglu skaits pārsniedza 400 000, un lapas mijiedarbība kļuva ārkārtīgi lēna vai pat neizmantojama. Galvenie atsaucības rādītāji, piemēram, Mijiedarbība līdz nākamajai krāsošanai (INP), pārsniedza pieņemamos līmeņus, radot lietotājiem taustāmu ievades aizkaves sajūtu. Šis raksts iedziļinās GitHub detalizētajā ceļā, lai dramatiski uzlabotu šos galvenos veiktspējas rādītājus, pārveidojot difu pārskatīšanas pieredzi.

Pārvarot veiktspējas vājās vietas: Daudzstratēģiju pieeja

Uzsākot veiktspējas izpēti cilnei Mainītie faili, ātri kļuva skaidrs, ka ar vienu "burvju lodes" risinājumu nepietiks. Metodes, kas paredzētas, lai saglabātu katru funkciju un pārlūkprogrammas iebūvēto uzvedību, bieži vien sasniedza griestus pie ekstrēmām datu slodzēm. Turpretī mazināšanas pasākumi, kas bija vērsti tikai uz to, lai novērstu sliktākos scenārijus, varēja radīt nelabvēlīgas kompromisu ikdienas pārskatīšanā.

Tā vietā GitHub inženieru komanda izstrādāja visaptverošu stratēģiju kopumu, katra rūpīgi izstrādāta, lai risinātu konkrētus izmaiņu pieprasījumu izmērus un sarežģītības pakāpes. Šīs stratēģijas tika veidotas uz trim galvenajām tēmām:

Mērķtiecīga difu rindu komponentu optimizācija: Veiktspējas uzlabošana primārajai difu pieredzei lielākajai daļai izmaiņu pieprasījumu. Tas nodrošināja, ka vidējas un lielas pārskatīšanas palika ātras, neapdraudot sagaidāmās funkcijas, piemēram, vietējo meklēšanu lapā.
Pakāpeniska veiktspējas samazināšana ar virtualizāciju: Lietojamības nodrošināšana lielākajiem izmaiņu pieprasījumiem, prioritāti piešķirot atsaucībai un stabilitātei, un inteliģenti ierobežojot to, kas tiek renderēts jebkurā brīdī.
Investīcijas pamatkomponentos un renderēšanas uzlabojumos: Uzlabojumu ieviešana, kas dod kumulatīvus ieguvumus visos izmaiņu pieprasījumu izmēros, neatkarīgi no lietotāja specifiskā skatīšanās režīma.

Šie stratēģiskie pīlāri vadīja komandas centienus, ļaujot viņiem sistemātiski risināt veiktspējas problēmu pamatcēloņus un sagatavot pamatu turpmākām arhitektūras pilnveidošanām.

V1 dekonstrukcija: Dārgas difu rindas izmaksas

GitHub sākotnējā uz React balstītā implementācija, ko sauc par v1, lika pamatu mūsdienu difu skatam. Šī versija bija nopietns mēģinājums pārnest klasisko Rails skatu uz React, prioritāti piešķirot mazu, atkārtoti izmantojamu React komponentu izveidei un skaidras DOM koka struktūras uzturēšanai. Tomēr šī pieeja, lai gan sākotnēji loģiska, izrādījās ievērojams šķērslis mērogā.

V1 versijā katras difu rindas renderēšana bija dārga operācija. Viena rinda apvienotā skatā parasti nozīmēja aptuveni 10 DOM elementus, savukārt sadalītā skatā bija nepieciešami aptuveni 15. Šis skaits vēl vairāk palielinājās ar sintakses izcelšanu, ieviešot daudz vairāk <span> tagu. React līmenī apvienotie difi saturēja vismaz astoņus komponentus uz vienu rindu, un sadalītajos skatos vismaz 13. Šie bija bāzes skaits, ar papildu UI stāvokļiem, piemēram, komentāriem, virsū peldošiem elementiem un fokusēšanu, pievienojot vēl vairāk komponentu.

V1 arhitektūra cieta arī no React notikumu apstrādātāju izplatības. Lai gan šķietami nekaitīgi mazā mērogā, viena difu rinda varēja saturēt 20 vai vairāk notikumu apstrādātāju. Reizinot to ar tūkstošiem rindu lielā izmaiņu pieprasījumā, tas ātri palielinājās, radot pārmērīgu izmaksu un palielinātu JavaScript atmiņas apgabala izmantošanu. Šī sarežģītība ietekmēja ne tikai veiktspēju, bet arī apgrūtināja izstrādi un uzturēšanu. Sākotnējais dizains, kas bija efektīvs ierobežotiem datiem, ievērojami cīnījās, saskaroties ar GitHub daudzveidīgo izmaiņu pieprasījumu neierobežoto raksturu.

Rezumējot, katrai v1 difa rindai sistēmai bija:

Vismaz 10-15 DOM koka elementi
Vismaz 8-13 React komponenti
Vismaz 20 React notikumu apstrādātāji
Daudz mazu, atkārtoti izmantojamu React komponentu

Šī arhitektūra tieši korelēja lielākus izmaiņu pieprasījumu izmērus ar lēnāku INP un palielinātu JavaScript atmiņas apgabala izmantošanu, nepieciešot fundamentālu pārvērtēšanu un pārprojektēšanu.

Renderēšanas revolūcija: V2 optimizācijas ietekme

Pāreja uz v2 iezīmēja būtisku arhitektūras pārveidošanu, koncentrējoties uz sīkām, ietekmīgām izmaiņām. Komanda pieņēma filozofiju, ka "neviena izmaiņa nav pārāk maza, ja runa ir par veiktspēju, īpaši liela mērogā". Izcils piemērs bija nevajadzīgo <code> tagu noņemšana no rindu numuru šūnām. Lai gan divu DOM mezglu noņemšana uz vienu difa rindu var šķist nenozīmīga, 10 000 rindu gadījumā tas nekavējoties nozīmēja par 20 000 mazāk mezglu DOM kokā, parādot, kā mērķtiecīgas, inkrementālas optimizācijas dod ievērojamus uzlabojumus.

Zemāk redzamais vizuālais salīdzinājums izceļ samazināto sarežģītību no v1 uz v2 komponentu līmenī:

V1 difa komponenti un HTML. Vienai difa rindai bija 8 React komponenti. V2 difa komponenti un HTML. Vienai difa rindai bija 3 React komponenti.

Vienkāršota komponentu arhitektūra

Galvenā inovācija v2 versijā bija komponentu koka vienkāršošana. Komanda pārgāja no astoņiem React komponentiem uz vienu difa rindu uz diviem. Tas tika panākts, novēršot dziļi ligzdotus komponentu kokus un izveidojot īpašus komponentus katrai sadalītajai un apvienotajai difa rindai. Lai gan tas ieviesa zināmu koda dublēšanos, tas krasi vienkāršoja datu piekļuvi un samazināja kopējo sarežģītību. Notikumu apstrāde tika arī centralizēta, tagad to pārvalda viens augstākā līmeņa apstrādātājs, izmantojot data-attribute vērtības, aizstājot daudzos individuālos v1 notikumu apstrādātājus. Šī pieeja ievērojami racionalizēja gan kodu, gan veiktspēju.

Inteliģenta stāvokļa pārvaldība un O(1) datu piekļuve

Iespējams, vislielākā ietekme bija sarežģītu lietojumprogrammas stāvokļa, piemēram, komentēšanas un konteksta izvēlņu, pārvietošanai uz nosacīti renderētiem bērnu komponentiem. Tādā vidē kā GitHub, kur izmaiņu pieprasījumi var pārsniegt tūkstošiem rindu, ir neefektīvi, ja katra rinda satur sarežģītu komentēšanas stāvokli, ja tikai neliela daļa kādreiz tiks komentēta. Pārvietojot šo stāvokli uz ligzdotiem komponentiem, difu rindu komponenta primārā atbildība kļuva tīri koda renderēšana, saskaņojot ar Viena Atbildības Principu.

Turklāt v2 risināja O(n) meklējumu un pārmērīgu useEffect āķu problēmu, kas nomocīja v1. Komanda pieņēma divu daļu stratēģiju: stingri ierobežojot useEffect lietošanu tikai augstākā līmeņa difu failiem un izveidojot lintēšanas noteikumus, lai novērstu to atkārtotu ieviešanu rindu aptverošos komponentos. Tas nodrošināja precīzu memoizāciju un paredzamu uzvedību. Vienlaikus globālie un difu stāvokļa automāti tika pārveidoti, lai izmantotu O(1) konstanta laika meklēšanu, izmantojot JavaScript Map objektus. Tas nodrošināja ātru, konsekventu selektoru izmantošanu biežām operācijām, piemēram, rindu atlasei un komentāru pārvaldībai, ievērojami uzlabojot koda kvalitāti, uzlabojot veiktspēju un samazinot sarežģītību, uzturot saplacinātas, kartētas datu struktūras. Šī rūpīgā pieeja izstrādātāju darba plūsmu optimizēšanai un pamatā esošajai arhitektūrai nodrošina stabilu, mērogojamu sistēmu.

Izmērāmā ietekme: V2 nodrošina kvantitatīvus ieguvumus

Rūpīgās arhitektūras un koda līmeņa optimizācijas, kas ieviestas v2, deva dziļus, kvantitatīvi izmērāmus uzlabojumus galvenajos veiktspējas rādītājos. Jaunā sistēma darbojas ievērojami ātrāk, ar milzīgu samazinājumu JavaScript atmiņas apgabalā un INP rādītājos. Šajā tabulā parādīti dramatiskie uzlabojumi, kas novēroti reprezentatīvā izmaiņu pieprasījumā ar 10 000 rindu izmaiņām sadalītā difa iestatījumā:

Metrika	v1	v2	Uzlabojums
JavaScript atmiņas apgabals	1GB+	250MB	75%
DOM mezgli	400 000+	80 000	80%
INP p95	1000ms+	100ms	90%

Šie skaitļi pasvītro GitHub daudzpusīgās stratēģijas panākumus. 75% samazinājums JavaScript atmiņas apgabalā un 80% samazinājums DOM mezglos nozīmē ne tikai vieglāku pārlūkprogrammas pēdu, bet arī tieši veicina stabilāku un atsaucīgāku saskarni. Visievērojamākais uzlabojums, 90% samazinājums INP p95 (95. procentile mijiedarbības latentumam), nozīmē, ka 95% lietotāja mijiedarbību tagad tiek pabeigtas tikai 100 milisekundēs, praktiski novēršot ievades aizkavi, kas nomocīja lielus izmaiņu pieprasījumus v1 versijā. Tas ievērojami uzlabo lietotāja pieredzi, padarot lielas koda pārskatīšanas tik plūstošas un atsaucīgas kā mazākas.

GitHub apņemšanās nepārtraukti uzlaboties, ko apliecina šī dziļā iedziļināšanās difu rindu optimizācijā, ir apliecinājums viņu centieniem nodrošināt pasaules klases izstrādātāju platformu. Rūpīgi analizējot veiktspējas vājās vietas un īstenojot mērķtiecīgus arhitektūras risinājumus, viņi ir ne tikai atrisinājuši kritiskas mērogojamības problēmas, bet arī noteikuši jaunu standartu atsaucībai savā galvenajā produktā. Šī koncentrēšanās uz veiktspēju nodrošina, ka inženieri var efektīvi veikt tādus svarīgus uzdevumus kā koda pārskatīšana, galu galā novedot pie augstākas koda kvalitātes un drošības un produktīvākas izstrādes vides.

Sākotnējais avots

https://github.blog/engineering/architecture-optimization/the-uphill-climb-of-making-diff-lines-performant/

Bieži uzdotie jautājumi

What is the 'Files changed' tab in GitHub pull requests and why was its performance critical?

The 'Files changed' tab is a core component of GitHub's pull request workflow, allowing engineers to review code modifications. Its performance is critical because it's where developers spend significant time, and slowdowns, especially with large pull requests, can severely impede productivity and user experience. GitHub prioritized its optimization to ensure responsiveness across all scales of code changes, from minor fixes to extensive refactorings, which can involve millions of lines across thousands of files. Maintaining a smooth and efficient review process is paramount for collaborative development.

What were the primary performance challenges GitHub faced with large pull requests in the v1 architecture?

In its initial React-based architecture (v1), GitHub encountered significant performance degradation when handling large pull requests. Key issues included the JavaScript heap exceeding 1 GB, DOM node counts soaring past 400,000, and page interactions becoming extremely sluggish or even unusable. The Interaction to Next Paint (INP) metric, which measures responsiveness, showed unacceptably high values. These problems stemmed from an inefficient rendering strategy where each diff line was resource-intensive, with too many DOM elements, React components, and event handlers, particularly in cases involving thousands of lines of code.

How did GitHub approach solving the complex performance issues, moving beyond a 'silver bullet' solution?

Recognizing that no single solution would address the diverse range of pull request sizes and complexities, GitHub adopted a multi-faceted strategic approach. They focused on three core themes: targeted optimizations for diff-line components to keep medium and large reviews fast, graceful degradation with virtualization to maintain usability for the largest pull requests by limiting rendered content, and investing in foundational components and rendering improvements to yield compounding benefits across all pull request sizes. This comprehensive strategy allowed them to tailor solutions to specific problem areas.

What were the key limitations of the 'v1' diff rendering architecture that made it unsustainable for scale?

The v1 architecture, while initially sensible for smaller diffs, proved unsustainable for large-scale pull requests. Each diff line was costly, requiring 10-15 DOM elements, 8-13 React components, and over 20 event handlers. This was compounded by deep component nesting, excessive `useEffect` hooks, and O(n) data lookups, leading to unnecessary re-renders and increased complexity. The abstraction layers, meant to share code, inadvertently added overhead by carrying logic for both split and unified views, even when only one was active. This design led to a significant increase in JavaScript heap, DOM count, and poor INP scores for larger diffs.

What specific architectural changes were implemented in 'v2' to drastically improve diff line performance?

The v2 architecture introduced several critical changes. It streamlined the component tree, reducing React components per diff line from eight to two by creating dedicated components for split and unified views, even with some code duplication. Event handling was centralized to a single top-level handler using `data-attribute` values, replacing numerous individual handlers. Complex app state, such as commenting features, was moved into conditionally rendered child components, ensuring that diff lines primarily focused on rendering code. Furthermore, v2 restricted `useEffect` hooks to top-level diff files and adopted O(1) constant-time data access using `JavaScript Map` for efficient state lookups, significantly reducing re-renders and improving data management.

How did the GitHub engineering team achieve quantifiable improvements in JavaScript heap, DOM nodes, and INP metrics with v2?

The cumulative effect of v2's architectural changes led to substantial quantifiable improvements. For a pull request with 10,000 line changes, the JavaScript heap size was reduced from 1GB+ to 250MB, a 75% improvement. DOM nodes decreased from 400,000+ to 80,000, an 80% reduction. The Interaction to Next Paint (INP) p95 (95th percentile) saw an astounding 90% improvement, dropping from 1000ms+ to just 100ms. These results were achieved through meticulous optimization, including removing extraneous DOM elements, simplifying the React component structure, centralizing event handling, and optimizing state management and data access patterns, leading to a much faster and more responsive user experience.

What is Interaction to Next Paint (INP) and why is its improvement significant for GitHub's user experience?

Interaction to Next Paint (INP) is a crucial web performance metric that assesses a page's responsiveness by measuring the latency of all interactions made by a user with the page. It records the time from when a user interacts (e.g., click, tap, keypress) until the next frame is painted to the screen, reflecting the visual feedback of that interaction. For GitHub, a high INP meant users experienced noticeable input lag, making the platform feel slow and unresponsive. By reducing INP p95 from over 1000ms to 100ms in v2, GitHub significantly enhanced the perceived speed and fluidity of the 'Files changed' tab, ensuring a smoother and more satisfying developer experience, especially during code review.

Esiet informēti

Saņemiet jaunākās AI ziņas savā e-pastā.

Dalīties