Diff-ridade jõudlus: GitHubi raske tee optimeerimiseni

GitHubi raske tee: Diff-ridade optimeerimine tipptulemuse saavutamiseks

Tõmbetaotlused on GitHubi elav süda, kus lugematud insenerid veedavad märkimisväärse osa oma tööelust. Arvestades GitHubi tohutut ulatust, mis hõlmab tõmbetaotlusi alates väikestest ühe rea parandustest kuni tuhandete failide ja miljonite ridade suurte muudatusteni, peab ülevaatamiskogemus jääma erakordselt kiireks ja reageerimisvõimeliseks. Hiljuti välja toodud uus Reactil põhinev kogemus vahekaardil Muudetud failid, mis on nüüd kõigi kasutajate vaikimisi valik, tähistas olulist investeeringut tugeva jõudluse tagamiseks, eriti nende keeruliste suurte tõmbetaotluste puhul. See pühendumus hõlmas järjepidevalt raskete probleemide lahendamist, nagu optimeeritud renderdamine, interaktsiooni latentsus ja mälukasutus.

Enne neid optimeerimisi, kuigi enamik kasutajaid nautis reageerivat kogemust, viisid suured tõmbetaotlused paratamatult märgatava jõudluse languseni. Ekstreemsetel juhtudel ületas JavaScripti mälu (heap) 1 GB, DOM-sõlmede arv ületas 400 000 ja lehe interaktsioonid muutusid äärmiselt aeglaseks või isegi kasutuskõlbmatuks. Peamised reageerimisvõime mõõdikud, nagu Interaktsioon kuni järgmise kuvamiseni (INP), tõusid üle vastuvõetavate tasemete, luues kasutajatele tajutava sisestuse viivituse tunde. See artikkel käsitleb üksikasjalikult teekonda, mille GitHub ette võttis, et neid põhilisi jõudluse mõõdikuid dramaatiliselt parandada, muutes diff-ide ülevaatamise kogemust.

Jõudluse pudelikaeltest navigeerimine: mitmestrateegiline lähenemine

Kui alustati vahekaardi Muudetud failid jõudlusuuringut, sai kiiresti selgeks, et üksikust "hõbekuuli" lahendusest ei piisa. Tehnikad, mis on loodud iga funktsiooni ja brauseri loomupärase käitumise säilitamiseks, jõudsid ekstreemsete andmemahtude korral sageli piirini. Vastupidi, leevendused, mis on suunatud ainult halvimate stsenaariumide vältimisele, võivad igapäevaste ülevaatuste puhul kaasa tuua ebasoodsaid kompromisse.

Selle asemel töötas GitHubi insenerimeeskond välja tervikliku strateegiate komplekti, millest igaüks oli hoolikalt kavandatud vastama konkreetsetele tõmbetaotluste suurustele ja keerukustele. Need strateegiad ehitati kolme põhipunkti ümber:

Sihitud optimeerimised diff-rea komponentidele: Esmasel diff-kogemusel enamiku tõmbetaotluste jaoks tõhususe suurendamine. See tagas, et keskmised ja suured ülevaatused jäid kiireks, ilma et oleks tehtud kompromisse oodatavate funktsioonide, nagu native find-in-page, osas.
Järkjärguline jõudluse vähenemine virtualiseerimisega: Kasutatavuse tagamine suurimate tõmbetaotluste puhul, seades esikohale reageerimisvõime ja stabiilsuse ning piirates arukalt hetkel renderdatavat sisu.
Investeering põhikomponentidesse ja renderdamise täiustustesse: Rakendades täiustusi, mis annavad liitkasu iga tõmbetaotluse suuruse puhul, sõltumata kasutaja konkreetsest vaatamisrežiimist.

Need strateegilised samad juhtisid meeskonna jõupingutusi, võimaldades neil süstemaatiliselt tegeleda jõudlusprobleemide algpõhjustega ja luua aluse järgnevatele arhitektuurilistele täiustustele.

V1 dekonstrueerimine: kuluka diff-rea hind

GitHubi esialgne Reactil põhinev juurutus, mida nimetatakse v1-ks, pani aluse kaasaegsele diff-vaatele. See versioon oli tõsine katse kanda klassikaline Railsi vaade Reacti, seades esikohale väikeste, korduvkasutatavate Reacti komponentide loomise ja selge DOM-puu struktuuri säilitamise. Kuid see lähenemine, kuigi algselt loogiline, osutus mastaabimisel märkimisväärseks pudelikaelaks.

V1-s oli iga diff-rea renderdamine kulukas operatsioon. Üks rida ühendatud vaates tähendas tavaliselt umbes 10 DOM-elementi, samal ajal kui jagatud vaade vajas ligikaudu 15. See arv suurenes veelgi süntaksi esiletõstmisega, lisades palju rohkem <span> silte. Reacti kihis sisaldasid ühendatud diffid vähemalt kaheksa komponenti rea kohta ja jagatud vaated vähemalt 13. Need olid algtaseme arvud, kus lisaliidese olekud, nagu kommentaarid, hõljumine ja fookus, lisasid veelgi komponente.

V1 arhitektuur kannatas ka Reacti sündmusekäitlejate leviku all. Kuigi väikeses mastaabis näiliselt kahjutu, võis üks diff-rida kanda 20 või enam sündmusekäitlejat. Kui see korrutada tuhandete ridadega suures tõmbetaotluses, suurenes see kiiresti, mis viis liigse üldkulu ja JavaScripti mälu suurenenud kasutamiseni. See keerukus ei mõjutanud mitte ainult jõudlust, vaid muutis ka arenduse ja hoolduse keerulisemaks. Esialgne disain, mis oli piiratud andmete puhul tõhus, nägi oluliselt vaeva GitHubi erinevate tõmbetaotluste piiramatu iseloomuga silmitsi seistes.

Kokkuvõttes oli süsteemis iga v1 diff-rea kohta:

Vähemalt 10-15 DOM-puu elementi
Vähemalt 8-13 Reacti komponenti
Vähemalt 20 Reacti sündmusekäitlejat
Arvukalt väikseid, korduvkasutatavaid Reacti komponente

See arhitektuur korreleeris suuremaid tõmbetaotluste suurusi aeglasema INP-ga ja suurenenud JavaScripti mälu kasutamisega, nõudes fundamentaalset ümberhindamist ja ümberkujundamist.

Renderdamise revolutsioon: V2 optimeerimiste mõju

Üleminek v2-le tähistas märkimisväärset arhitektuurilist ümberkorraldust, keskendudes detailsetele ja mõjukatele muudatustele. Meeskond võttis omaks filosoofia, et "jõudluse osas pole ükski muudatus liiga väike, eriti mastaabis." Peamine näide oli mittevajalike <code> siltide eemaldamine reanumbri lahtritest. Kuigi kahe DOM-sõlme eemaldamine diff-rea kohta võib tunduda tühine, tähendas see 10 000 rea puhul koheselt 20 000 DOM-is vähem sõlme, näidates, kuidas sihipärased, inkrementaalsed optimeerimised annavad olulisi täiustusi.

Alljärgnev visuaalne võrdlus rõhutab keerukuse vähenemist v1-lt v2-le komponendi tasemel:

V1 Diff Components and HTML. We had 8 react components for a single diff line. V2 Diff Components and HTML. We had 3 react components for a single diff line.

Ühtlustatud komponendi arhitektuur

V2 põhiuuendus seisnes komponendi puu lihtsustamises. Meeskond vähendas Reacti komponente diff-rea kohta kaheksalt kahele. See saavutati sügavalt pesastatud komponendi puude kõrvaldamisega ja spetsiaalsete komponentide loomisega iga jagatud ja ühendatud diff-rea jaoks. Kuigi see tõi kaasa mõningase koodi dubleerimise, lihtsustas see drastiliselt andmetele juurdepääsu ja vähendas üldist keerukust. Sündmuste käsitlemine tsentraliseeriti samuti, seda haldab nüüd üks tipptaseme käitleja, kasutades data-attribute väärtusi, asendades v1 arvukad individuaalsed sündmusekäitlejad. See lähenemine ühtlustas drastiliselt nii koodi kui ka jõudlust.

Arukas olekuhaldus ja O(1) andmetele juurdepääs

Võib-olla kõige mõjukam muudatus oli keerulise rakenduse oleku, nagu kommenteerimine ja kontekstimenüüd, ümberpaigutamine tingimuslikult renderdatud alamkomponentidesse. GitHubi keskkonnas, kus tõmbetaotlused võivad ületada tuhandeid ridu, on ebatõhus, kui iga rida kannab keerulist kommenteerimisolekut, kui vaid väike osa neist kunagi kommentaare sisaldab. Selle oleku pesastatud komponentidesse viimisega sai diff-rea komponendi peamiseks ülesandeks puhtalt koodi renderdamine, mis oli kooskõlas ühekordse vastutuse põhimõttega.

Lisaks lahendas v2 O(n) otsingute ja liigsete useEffect konksude probleemi, mis v1-s esinesid. Meeskond võttis kasutusele kahest osast koosneva strateegia: piiras rangelt useEffect kasutamist ainult diff-failide tipptasemel ja kehtestas linting-reeglid, et vältida nende taaskasutamist rida-pakendavates komponentides. See tagas täpse memoisatsiooni ja ennustatava käitumise. Samal ajal kujundati globaalsed ja diff-olekumasinad ümber, et kasutada O(1) konstantaegseid otsinguid, kasutades JavaScripti Map objekte. See võimaldas kiireid ja järjepidevaid selektoreid levinud toiminguteks, nagu rea valik ja kommentaaride haldus, parandades oluliselt koodi kvaliteeti, suurendades jõudlust ja vähendades keerukust, säilitades lapikud, kaardistatud andmestruktuurid. See pedantne lähenemine arendaja töövoogude ja aluseks oleva arhitektuuri optimeerimisele tagab tugeva ja skaleeruva süsteemi.

Mõõdetav mõju: V2 toob kvantifitseeritavaid kasu

V2-s rakendatud hoolikad arhitektuurilised ja kooditaseme optimeerimised andsid sügavaid ja kvantifitseeritavaid parandusi peamistes jõudluse mõõdikutes. Uus süsteem töötab oluliselt kiiremini, vähendades oluliselt JavaScripti mälu kasutust ja INP-skoore. Järgmine tabel näitab dramaatilisi parandusi, mis täheldati esinduslikul tõmbetaotlusel 10 000 rea muutusega jagatud diff-seades:

Mõõdik	v1	v2	Paranemine
JavaScripti mälu	1GB+	250MB	75%
DOM-sõlmed	400,000+	80,000	80%
INP p95	1000ms+	100ms	90%

Need arvud rõhutavad GitHubi mitmetahulise strateegia edukust. 75% JavaScripti mälu suuruse vähenemine ja 80% DOM-sõlmede vähenemine ei tähenda mitte ainult kergemat brauseri koormust, vaid aitab otseselt kaasa stabiilsema ja reageerimisvõimelisema liidese loomisele. Kõige silmatorkavam paranemine, 90% vähenemine INP p95-s (interaktsiooni latentsuse 95. protsentiil), tähendab, et 95% kasutaja interaktsioonidest viiakse nüüd läbi vaid 100 millisekundi jooksul, kõrvaldades praktiliselt sisestuse viivituse, mis vaevas v1 suurte tõmbetaotluste korral. See parandab oluliselt kasutajakogemust, muutes suured koodiülevaatused tunduma sama sujuvate ja reageerimisvõimelistena kui väiksemad.

GitHubi pühendumus pidevale arengule, mida tõendab see sügav sukeldumine diff-rea optimeerimisse, on tunnistus nende pühendumusest pakkuda maailmatasemel arendaja platvormi. Hoolika jõudluse pudelikaelte analüüsi ja sihipäraste arhitektuuriliste lahenduste rakendamise kaudu on nad mitte ainult lahendanud kriitilised skaleeruvuse probleemid, vaid seadnud ka uue standardi oma põhitoodete reageerimisvõimele. See keskendumine jõudlusele tagab, et insenerid saavad tõhusalt tegeleda oluliste ülesannetega, nagu koodiülevaatused, mis viib lõppkokkuvõttes kõrgema koodikvaliteedi ja turvalisuseni ning tootlikuma arenduskeskkonnani.

Algallikas

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

Korduma kippuvad küsimused

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.

Püsige kursis

Saage värskeimad AI uudised oma postkasti.

Jaga