Eilučių skirtumų našumas: „GitHub“ sunkus kelias optimizuoti

title: "Eilučių skirtumų našumas: „GitHub“ sunkus kelias optimizuoti" slug: "the-uphill-climb-of-making-diff-lines-performant" date: "2026-04-06" lang: "lt" source: "https://github.blog/engineering/architecture-optimization/the-uphill-climb-of-making-diff-lines-performant/" category: "Kūrėjo įrankiai" keywords:

• GitHub
• Patraukimo užklausos
• Našumo optimizavimas
• Eilučių skirtumai
• React kūrimas
• Interneto našumas
• DOM optimizavimas
• JavaScript krūva
• Sąveika iki kito piešinio (INP)
• Programinės įrangos architektūra
• Komponentų dizainas
• Sąsajos inžinerija meta_description: "„GitHub“ inžinierių komanda išsamiai aprašo savo kruopštų kelią optimizuojant eilučių skirtumų našumą patraukimo užklausose, smarkiai sumažinant JavaScript krūvą, DOM mazgus ir pagerinant INP." image: "/images/articles/the-uphill-climb-of-making-diff-lines-performant.png" image_alt: "Diagrama, rodanti našumo pagerėjimus „GitHub“ eilučių skirtumuose, pabrėžiant sumažintus DOM mazgus ir JavaScript krūvą optimizuotame rodinyje." quality_score: 94 content_score: 93 seo_score: 95 companies:
• GitHub schema_type: "NewsArticle" reading_time: 7 faq:
• question: "Kas yra „Pakeisti failai“ (Files changed) skirtukas „GitHub“ patraukimo užklausose ir kodėl jo našumas buvo kritinis?" answer: "„Pakeisti failai“ skirtukas yra pagrindinė „GitHub“ patraukimo užklausų darbo eigos dalis, leidžianti inžinieriams peržiūrėti kodo pakeitimus. Jo našumas yra kritinis, nes būtent ten kūrėjai praleidžia daug laiko, o sulėtėjimai, ypač su didelėmis patraukimo užklausomis, gali smarkiai pakenkti produktyvumui ir vartotojo patirčiai. „GitHub“ pirmenybę teikė optimizavimui, siekdama užtikrinti reagavimą visais kodo pakeitimų mastais, nuo smulkių pataisymų iki plataus masto refaktorinimo, kuris gali apimti milijonus eilučių tūkstančiuose failų. Sklandaus ir efektyvaus peržiūros proceso palaikymas yra itin svarbus bendradarbiaujant kuriant."
• question: "Su kokiais pagrindiniais našumo iššūkiais „GitHub“ susidūrė dėl didelių patraukimo užklausų v1 architektūroje?" answer: "Pradinėje savo React pagrindu veikiančioje architektūroje (v1), „GitHub“ susidūrė su dideliu našumo pablogėjimu tvarkant dideles patraukimo užklausas. Pagrindinės problemos apėmė JavaScript krūvą, viršijančią 1 GB, DOM mazgų skaičių, viršijantį 400 000, ir puslapio sąveikas, tapusias itin lėtomis ar net nenaudojamomis. Sąveika iki kito piešinio (INP) metrika, matuojanti reagavimą, parodė nepriimtinai dideles vertes. Šios problemos kilo dėl neefektyvios atvaizdavimo strategijos, kur kiekviena skirtumo eilutė reikalavo daug išteklių, turėjo per daug DOM elementų, React komponentų ir įvykių tvarkyklių, ypač tais atvejais, kai buvo tūkstančiai kodo eilučių."
• question: "Kaip „GitHub“ sprendė sudėtingas našumo problemas, neapsiribojant „sidabrinės kulkos“ sprendimu?" answer: "Pripažindama, kad joks vienas sprendimas neišspręs įvairių patraukimo užklausų dydžių ir sudėtingumo, „GitHub“ priėmė daugialypį strateginį požiūrį. Jie sutelkė dėmesį į tris pagrindines temas: tikslines skirtumo eilučių komponentų optimizacijas, kad vidutinės ir didelės peržiūros išliktų greitos, laipsnišką našumo mažinimą su virtualizacija, siekiant išlaikyti didžiausių patraukimo užklausų naudojamumą, apribojant atvaizduojamą turinį, ir investavimą į pagrindinius komponentus bei atvaizdavimo patobulinimus, kad būtų pasiekta didesnė nauda visų dydžių patraukimo užklausoms. Ši išsami strategija leido pritaikyti sprendimus konkrečioms problemoms."
• question: "Kokie buvo pagrindiniai „v1“ skirtumų atvaizdavimo architektūros apribojimai, dėl kurių ji tapo netinkama masteliui?" answer: "V1 architektūra, nors iš pradžių logiška mažesniems skirtumams, pasirodė netvari didelio masto patraukimo užklausoms. Kiekviena skirtumo eilutė buvo brangi, reikalaujanti 10-15 DOM elementų, 8-13 React komponentų ir daugiau nei 20 įvykių tvarkyklių. Tai dar labiau apsunkino gilus komponentų įdėjimas, pernelyg didelis useEffect kabliukų naudojimas ir O(n) duomenų paieškos, kas lėmė nereikalingus perspausdininimus ir didesnį sudėtingumą. Abstrakcijos sluoksniai, skirti bendrinti kodą, netyčia sukėlė papildomų sąnaudų, nešdami logiką tiek padalintam, tiek sujungtam rodiniui, net kai buvo aktyvus tik vienas. Šis dizainas lėmė žymiai padidėjusią JavaScript krūvą, DOM elementų skaičių ir prastus INP balus didesniems skirtumams."
• question: "Kokie konkretūs architektūriniai pakeitimai buvo įdiegti „v2“, siekiant drastiškai pagerinti eilučių skirtumų našumą?" answer: "V2 architektūra įdiegė keletą kritinių pakeitimų. Ji supaprastino komponentų medį, sumažindama React komponentų skaičių vienai skirtumo eilutei nuo aštuonių iki dviejų, sukurdama dedikuotus komponentus padalintiems ir sujungtiems rodiniams, net ir su tam tikru kodo dubliavimu. Įvykių tvarkymas buvo centralizuotas į vieną aukščiausio lygio tvarkyklę, naudojant data-attribute reikšmes, pakeičiant daugybę atskirų tvarkyklių. Sudėtinga programos būsena, pvz., komentavimo funkcijos, buvo perkelta į sąlygiškai atvaizduojamus dukterinius komponentus, užtikrinant, kad skirtumų eilutės pirmiausia sutelktų dėmesį į kodo atvaizdavimą. Be to, v2 apribojo useEffect kabliukų naudojimą aukščiausio lygio skirtumų failams ir pritaikė O(1) pastovaus laiko duomenų prieigą, naudojant JavaScript Map efektyvioms būsenos paieškoms, žymiai sumažinant perspausdininimus ir pagerinant duomenų valdymą."
• question: "Kaip „GitHub“ inžinierių komanda pasiekė kiekybiškai išmatuojamus JavaScript krūvos, DOM mazgų ir INP metrikos pagerėjimus su v2?" answer: "Kaupiamasis v2 architektūrinių pakeitimų poveikis lėmė reikšmingus kiekybiškai išmatuojamus patobulinimus. Patraukimo užklausai su 10 000 eilučių pakeitimų, JavaScript krūvos dydis buvo sumažintas nuo 1GB+ iki 250MB, o tai yra 75% pagerėjimas. DOM mazgų skaičius sumažėjo nuo 400 000+ iki 80 000, o tai yra 80% sumažėjimas. Sąveika iki kito piešinio (INP) p95 (95-asis procentilis) pasiekė stulbinantį 90% pagerėjimą, sumažėjo nuo 1000ms+ iki vos 100ms. Šie rezultatai buvo pasiekti kruopščiu optimizavimu, įskaitant nereikalingų DOM elementų pašalinimą, React komponentų struktūros supaprastinimą, įvykių tvarkymo centralizavimą ir būsenos valdymo bei duomenų prieigos šablonų optimizavimą, kas lėmė daug greitesnę ir labiau reaguojančią vartotojo patirtį."
• question: "Kas yra Sąveika iki kito piešinio (INP) ir kodėl jos pagerėjimas yra reikšmingas „GitHub“ vartotojo patirčiai?" answer: "Sąveika iki kito piešinio (INP) yra esminė žiniatinklio našumo metrika, kuri vertina puslapio reagavimą, matuodama visų vartotojo atliktų sąveikų su puslapiu vėlavimą. Ji registruoja laiką nuo tada, kai vartotojas sąveikauja (pvz., paspaudžia, paliečia, paspaudžia klavišą) iki kito kadro atvaizdavimo ekrane, atspindėdama vizualinį tos sąveikos atsaką. „GitHub“ atveju didelis INP reiškė, kad vartotojai patyrė pastebimą įvesties vėlavimą, todėl platforma atrodė lėta ir nereaguojanti. Sumažinus INP p95 nuo daugiau nei 1000 ms iki 100 ms v2 versijoje, „GitHub“ žymiai pagerino „Pakeisti failai“ (Files changed) skirtuko suvokiamą greitį ir sklandumą, užtikrindama sklandesnę ir labiau patenkinančią kūrėjo patirtį, ypač per kodo peržiūrą."

„GitHub“ sunkus kelias: skirtumų eilučių optimizavimas siekiant didžiausio našumo

Patraukimo užklausos yra gyvybinga GitHub šerdis, kurioje daugybė inžinierių skiria didelę savo profesinio gyvenimo dalį. Atsižvelgiant į didžiulį GitHub mastą, tvarkant patraukimo užklausas, kurios svyruoja nuo nedidelių vienos eilutės pataisymų iki kolosalių pakeitimų, apimančių tūkstančius failų ir milijonus eilučių, peržiūros patirtis turi išlikti išskirtinai greita ir reaguojanti. Neseniai įdiegta nauja React pagrindu veikianti Pakeistų failų skirtuko patirtis, dabar numatyta visiems vartotojams, žymi esminę investiciją į tvirto našumo užtikrinimą, ypač šioms sudėtingoms didelėms patraukimo užklausoms. Šis įsipareigojimas apėmė nuolatinį sudėtingų problemų, tokių kaip optimizuotas atvaizdavimas, sąveikos vėlavimas ir atminties suvartojimas, sprendimą.

Prieš šiuos optimizavimus, nors dauguma vartotojų mėgavosi reagavimo patirtimi, didelės patraukimo užklausos neišvengiamai lėmė pastebimą našumo pablogėjimą. Kraštutiniais atvejais JavaScript krūva viršijo 1 GB, DOM mazgų skaičius viršijo 400 000, o puslapio sąveikos tapo itin lėtos ar net nenaudojamos. Pagrindinės reagavimo metrikos, tokios kaip Sąveika iki kito piešinio (INP), pakilo virš priimtino lygio, sukurdamos apčiuopiamą įvesties vėlavimo jausmą vartotojams. Šis straipsnis išsamiai nagrinėja GitHub kelionę, siekiant dramatiškai pagerinti šias pagrindines našumo metrikas, pakeičiant skirtumų peržiūros patirtį.

Našumo kliūčių įveikimas: daugiasluoksnis požiūris

Pradėjus našumo tyrimą Pakeistų failų skirtukui, greitai paaiškėjo, kad vienas „sidabrinės kulkos“ sprendimas nebus pakankamas. Technikos, skirtos išsaugoti kiekvieną funkciją ir naršyklės integruotą elgseną, dažnai pasiekia ribą esant ekstremalioms duomenų apkrovoms. Ir atvirkščiai, priemonės, skirtos tik blogiausiems scenarijams išvengti, gali sukelti nepalankius kompromisus kasdienėms peržiūroms.

Vietoj to, „GitHub“ inžinierių komanda sukūrė išsamų strategijų rinkinį, kiekviena kruopščiai sukurta, kad išspręstų konkrečių patraukimo užklausų dydžius ir sudėtingumus. Šios strategijos buvo paremtos trimis pagrindinėmis temomis:

1. Tikslinės skirtumų eilučių komponentų optimizacijos: Pagrindinės skirtumų peržiūros efektyvumo didinimas daugeliui patraukimo užklausų. Tai užtikrino, kad vidutinės ir didelės peržiūros išliktų greitos, nepakenkiant numatytoms funkcijoms, tokioms kaip naršyklės paieška puslapyje.
2. Laipsniškas našumo mažinimas su virtualizacija: Didžiausių patraukimo užklausų naudojamumo užtikrinimas, pirmenybę teikiant reagavimui ir stabilumui bei protingai ribojant, kas yra atvaizduojama bet kuriuo metu.
3. Investicija į pagrindinius komponentus ir atvaizdavimo patobulinimus: Patobulinimų įdiegimas, kurie duoda didėjantį pranašumą visų dydžių patraukimo užklausoms, nepriklausomai nuo vartotojo pasirinkto rodinio režimo.

Šios strateginės gairės nukreipė komandos pastangas, leisdamos joms sistemingai spręsti našumo problemų priežastis ir paruošti dirvą vėlesniems architektūriniams patobulinimams.

V1 išardymas: brangios skirtumo eilutės kaina

Pradinė „GitHub“ React pagrindu veikianti implementacija, vadinama v1, padėjo pagrindus šiuolaikiniam skirtumų rodiniui. Ši versija buvo nuoširdžios pastangos perkelti klasikinį Rails rodinį į React, pirmenybę teikiant mažų, pakartotinai naudojamų React komponentų kūrimui ir aiškios DOM medžio struktūros palaikymui. Tačiau šis požiūris, nors ir logiškas jo pradžioje, pasirodė esąs didelis kliuvinys masteliu.

V1 versijoje kiekvienos skirtumo eilutės atvaizdavimas buvo brangi operacija. Viena eilutė sujungtame rodinyje paprastai reikšdavo apie 10 DOM elementų, o padalintame rodinyje – apie 15. Šis skaičius dar labiau padidėtų su sintaksės paryškinimu, įvedant daug daugiau <span> žymių. React lygyje, sujungti skirtumai turėjo mažiausiai aštuonis komponentus eilutei, o padalinti rodiniai – mažiausiai 13. Tai buvo baziniai skaičiai, su papildomomis vartotojo sąsajos būsenomis, tokiomis kaip komentarai, užvedimas ir fokusas, pridedant dar daugiau komponentų.

V1 architektūra taip pat kentėjo nuo React įvykių tvarkyklių gausos. Nors atrodytų nekenksminga mažame mastelyje, viena skirtumo eilutė galėjo turėti 20 ar daugiau įvykių tvarkyklių. Kai tai padauginama per tūkstančius eilučių didelėje patraukimo užklausoje, tai greitai kaupėsi, sukeldama pernelyg didelę apkrovą ir padidėjusį JavaScript krūvos naudojimą. Šis sudėtingumas ne tik paveikė našumą, bet ir apsunkino kūrimą bei priežiūrą. Pradinis dizainas, efektyvus ribotiems duomenims, gerokai sunkiai veikė susidūręs su neribotu „GitHub“ įvairių patraukimo užklausų dydžių pobūdžiu.

Apibendrinant, kiekvienai v1 skirtumo eilutei, sistema turėjo:

• Mažiausiai 10-15 DOM medžio elementų
• Mažiausiai 8-13 React komponentų
• Mažiausiai 20 React įvykių tvarkyklių
• Daugybę mažų, pakartotinai naudojamų React komponentų

Ši architektūra tiesiogiai susiejo didesnes patraukimo užklausas su lėtesniu INP ir padidėjusiu JavaScript krūvos naudojimu, todėl prireikė esminio persvarstymo ir perprojektavimo.

Atvaizdavimo revoliucija: V2 optimizacijų poveikis

Perėjimas prie v2 žymėjo esminį architektūrinį pertvarkymą, sutelkiant dėmesį į detalizuotus, reikšmingus pakeitimus. Komanda priėmė filosofiją, kad 'joks pakeitimas nėra per mažas, kai kalbama apie našumą, ypač dideliu mastu'. Puikus pavyzdys buvo nereikalingų <code> žymių pašalinimas iš eilutės numerių langelių. Nors dviejų DOM mazgų pašalinimas iš vienos skirtumo eilutės gali atrodyti nereikšmingas, per 10 000 eilučių tai iš karto prilygo 20 000 mažiau mazgų DOM medyje, parodydama, kaip tikslinės, laipsniškos optimizacijos duoda didelius patobulinimus.

Toliau pateiktas vizualinis palyginimas pabrėžia sumažintą sudėtingumą nuo v1 iki v2 komponentų lygiu:

Supaprastinta komponentų architektūra

Pagrindinė v2 inovacija apėmė komponentų medžio supaprastinimą. Komanda sumažino React komponentų skaičių vienai skirtumo eilutei nuo aštuonių iki dviejų. Tai buvo pasiekta pašalinant giliai įdėtus komponentų medžius ir sukuriant dedikuotus komponentus kiekvienai padalintai ir sujungtai skirtumo eilutei. Nors tai įvedė tam tikrą kodo dubliavimą, tai drastiškai supaprastino duomenų prieigą ir sumažino bendrą sudėtingumą. Įvykių tvarkymas taip pat buvo centralizuotas, dabar valdomas vieno aukščiausio lygio tvarkyklės, naudojant data-attribute reikšmes, pakeičiant daugybę atskirų v1 įvykių tvarkyklių. Šis požiūris drastiškai supaprastino tiek kodą, tiek našumą.

Išmanus būsenos valdymas ir O(1) duomenų prieiga

Galbūt pats reikšmingiausias pokytis buvo sudėtingos programos būsenos, pvz., komentavimo ir kontekstinių meniu, perkėlimas į sąlygiškai atvaizduojamus dukterinius komponentus. Aplinkoje, tokioje kaip „GitHub“, kur patraukimo užklausos gali viršyti tūkstančius eilučių, yra neefektyvu, kad kiekviena eilutė turėtų sudėtingą komentavimo būseną, kai tik maža dalis jų kada nors turės komentarų. Perkėlus šią būseną į įdėtus komponentus, skirtumų eilučių komponento pagrindinė atsakomybė tapo grynai kodo atvaizdavimas, atitinkantis vienos atsakomybės principą.

Be to, v2 išsprendė O(n) paieškų ir pernelyg didelio useEffect kabliukų naudojimo problemą, kuri kankino v1. Komanda pritaikė dviejų dalių strategiją: griežtai apribojo useEffect naudojimą aukščiausiam skirtumų failų lygiui ir nustatė lintingo taisykles, kad būtų išvengta jų pakartotinio įvedimo eilučių vyniojimo komponentuose. Tai užtikrino tikslų memoizavimą ir nuspėjamą elgesį. Tuo pačiu metu, globalios ir skirtumų būsenos mašinos buvo perprojektuotos, kad būtų galima naudoti O(1) pastovaus laiko paieškas, naudojant JavaScript Map objektus. Tai leido greitai ir nuosekliai pasirinkti bendras operacijas, tokias kaip eilučių pasirinkimas ir komentarų valdymas, žymiai pagerinant kodo kokybę, našumą ir sumažinant sudėtingumą, palaikant išlygintas, susietas duomenų struktūras. Šis kruopštus požiūris į kūrėjo darbo eigos optimizavimą ir pagrindinę architektūrą užtikrina tvirtą, keičiamo dydžio sistemą.

Išmatuojamas poveikis: V2 suteikia kiekybinių laimėjimų

Kruopščios architektūrinės ir kodo lygio optimizacijos, įdiegtos v2, davė gilių, kiekybiškai išmatuojamų patobulinimų pagrindinėse našumo metrikose. Nauja sistema veikia žymiai greičiau, su didžiuliu JavaScript krūvos naudojimo ir INP balų sumažėjimu. Toliau pateiktoje lentelėje parodyti dramatiški patobulinimai, pastebėti reprezentacinėje patraukimo užklausoje su 10 000 eilučių pakeitimų padalinto skirtumo nustatymuose:

Šie skaičiai pabrėžia „GitHub“ daugialypės strategijos sėkmę. 75% sumažėjimas JavaScript krūvos dydžio ir 80% sumažėjimas DOM mazgų skaičiaus ne tik reiškia lengvesnį naršyklės pėdsaką, bet ir tiesiogiai prisideda prie stabilesnės ir labiau reaguojančios sąsajos. Įspūdingiausias patobulinimas, 90% sumažinimas INP p95 (95-asis sąveikos vėlavimo procentilis), reiškia, kad 95% vartotojų sąveikų dabar užbaigiamos per vos 100 milisekundžių, praktiškai pašalinant įvesties vėlavimą, kuris kankino dideles patraukimo užklausas v1 versijoje. Tai žymiai pagerina vartotojo patirtį, todėl didelių kodo peržiūrų procesas jaučiamas taip pat sklandžiai ir reaguojančiai kaip ir mažesnių.

„GitHub“ įsipareigojimas nuolat tobulėti, patvirtintas šio išsamaus skirtumų eilučių optimizavimo tyrimo, liudija jų atsidavimą teikti pasaulinio lygio kūrėjo platformą. Kruopščiai analizuodami našumo kliūtis ir diegdami tikslinius architektūrinius sprendimus, jie ne tik išsprendė kritines mastelio problemas, bet ir nustatė naują reagavimo standartą savo pagrindiniame produkte. Šis dėmesys našumui užtikrina, kad inžinieriai galėtų efektyviai atlikti svarbias užduotis, tokias kaip kodo peržiūros, galiausiai vedančias į aukštesnę kodo kokybę ir saugumą ir produktyvesnę kūrimo aplinką.