டிஃப் வரிகளின் செயல்திறன்: GitHub-இன் மேம்படுத்துவதற்கான சவாலான பயணம்

GitHub-இன் சவாலான பயணம்: உச்ச செயல்திறனுக்காக டிஃப் வரிகளை மேம்படுத்துதல்

புல் ரிக்வெஸ்ட்கள் GitHub-இன் துடிப்பான மையமாக நிற்கின்றன, அங்கு எண்ணற்ற பொறியியலாளர்கள் தங்கள் தொழில் வாழ்க்கையின் கணிசமான பகுதியை அர்ப்பணிக்கின்றனர். GitHub-இன் மிகப்பெரிய அளவைக் கருத்தில் கொண்டால், சிறிய ஒரு-வரி திருத்தங்கள் முதல் ஆயிரக்கணக்கான கோப்புகள் மற்றும் மில்லியன் கணக்கான வரிகளைக் கொண்ட பெரிய மாற்றங்கள் வரையிலான புல் ரிக்வெஸ்ட்களைக் கையாளும் போது, மதிப்பாய்வு அனுபவம் விதிவிலக்காக வேகமாகவும் பதிலளிக்கக்கூடியதாகவும் இருக்க வேண்டும். புதிய React அடிப்படையிலான Files changed தளத்திற்கான அனுபவத்தின் சமீபத்திய வெளியீடு, இப்போது அனைத்து பயனர்களுக்கும் இயல்புநிலையாக உள்ளது, இது வலுவான செயல்திறனை உறுதி செய்வதில் ஒரு முக்கிய முதலீடாகும், குறிப்பாக இந்த சவாலான பெரிய புல் ரிக்வெஸ்ட்களுக்கு. இந்த அர்ப்பணிப்பில், மேம்படுத்தப்பட்ட ரெண்டரிங், இடைவினை தாமதம் மற்றும் நினைவக நுகர்வு போன்ற கடினமான சிக்கல்களைத் தொடர்ந்து கையாள்வது அடங்கும்.

இந்த மேம்பாடுகளுக்கு முன், பெரும்பாலான பயனர்கள் பதிலளிக்கக்கூடிய அனுபவத்தைப் பெற்றிருந்தாலும், பெரிய புல் ரிக்வெஸ்ட்கள் தவிர்க்க முடியாமல் கவனிக்கத்தக்க செயல்திறன் சரிவுக்கு வழிவகுத்தன. தீவிர நிகழ்வுகளில் JavaScript ஹீப் 1 GB-ஐத் தாண்டியது, DOM நோடுகளின் எண்ணிக்கை 400,000-ஐத் தாண்டியது, மற்றும் பக்க இடைவினைகள் மிக மெதுவாக அல்லது பயன்படுத்த முடியாத அளவுக்கு மாறின. Interaction to Next Paint (INP) போன்ற முக்கிய பதிலளிக்கக்கூடிய மெட்ரிக்ஸ் ஏற்றுக்கொள்ளக்கூடிய அளவுகளைத் தாண்டி உயர்ந்தது, பயனர்களுக்கு உள்ளீட்டு தாமதத்தின் ஒரு தெளிவான உணர்வை உருவாக்கியது. இந்த முக்கிய செயல்திறன் மெட்ரிக்ஸ்களை வியத்தகு முறையில் மேம்படுத்தவும், டிஃப் மதிப்பாய்வு அனுபவத்தை மாற்றவும் GitHub மேற்கொண்ட விரிவான பயணத்தை இந்தக் கட்டுரை ஆராய்கிறது.

செயல்திறன் இடையூறுகளை வழிநடத்துதல்: ஒரு பல-மூலோபாய அணுகுமுறை

Files changed தளத்திற்கான செயல்திறன் விசாரணையைத் தொடங்கும்போது, ஒரு ஒற்றை 'சில்வர் புல்லட்' தீர்வு போதுமானதாக இருக்காது என்பது விரைவில் தெளிவாகத் தெரிந்தது. ஒவ்வொரு அம்சத்தையும் மற்றும் உலாவி-இயல்பு நடத்தையையும் பாதுகாக்க வடிவமைக்கப்பட்ட நுட்பங்கள் பெரும்பாலும் தீவிர டேட்டா சுமைகளுடன் ஒரு உச்சத்தை எட்டின. மாறாக, மோசமான சூழ்நிலைகளைத் தடுப்பதை மட்டுமே நோக்கமாகக் கொண்ட தணிப்புகள் தினசரி மதிப்பாய்வுகளுக்கு விரும்பத்தகாத சமரசங்களை அறிமுகப்படுத்தலாம்.

மாறாக, GitHub-இன் பொறியியல் குழு ஒரு விரிவான மூலோபாய தொகுப்பை உருவாக்கியது, ஒவ்வொன்றும் குறிப்பிட்ட புல் ரிக்வெஸ்ட் அளவுகள் மற்றும் சிக்கல்களை நிவர்த்தி செய்ய உன்னிப்பாக வடிவமைக்கப்பட்டது. இந்த மூலோபாயங்கள் மூன்று முக்கிய அம்சங்களை அடிப்படையாகக் கொண்டிருந்தன:

டிஃப்-லைன் கூறுகளுக்கான இலக்கு மேம்பாடுகள்: பெரும்பாலான புல் ரிக்வெஸ்ட்களுக்கான முதன்மை டிஃப் அனுபவத்தின் திறனை மேம்படுத்துதல். இது நடுத்தர மற்றும் பெரிய மதிப்பாய்வுகள் உள்ளூர் 'ஃபைண்ட்-இன்-பேஜ்' போன்ற எதிர்பார்க்கப்படும் செயல்பாடுகளில் சமரசம் செய்யாமல் விரைவாக இருப்பதை உறுதிசெய்தது.
விர்ச்சுவலைசேஷனுடன் கூடிய கிரேஸ்ஃபுல் டீக்ரேடேஷன்: பதிலளிக்கக்கூடிய தன்மை மற்றும் நிலைத்தன்மைக்கு முன்னுரிமை அளிப்பதன் மூலம், மற்றும் எந்த ஒரு தருணத்திலும் ரெண்டர் செய்யப்படும் உள்ளடக்கத்தை புத்திசாலித்தனமாக கட்டுப்படுத்துவதன் மூலம், மிகப்பெரிய புல் ரிக்வெஸ்ட்களுக்குப் பயன்பாட்டினை உறுதி செய்தல்.
அடிப்படை கூறுகள் மற்றும் ரெண்டரிங் மேம்பாடுகளில் முதலீடு: பயனரின் குறிப்பிட்ட பார்வை முறையைப் பொருட்படுத்தாமல், ஒவ்வொரு புல் ரிக்வெஸ்ட் அளவிலும் கூட்டுப் பலன்களை அளிக்கும் மேம்பாடுகளைச் செயல்படுத்துதல்.

இந்த மூலோபாய தூண்கள் குழுவின் முயற்சிகளை வழிநடத்தின, செயல்திறன் சிக்கல்களின் அடிப்படைக் காரணங்களை முறையாகக் கையாளவும், அடுத்தடுத்த கட்டமைப்பு மேம்பாடுகளுக்கான களத்தை அமைக்கவும் அவர்களுக்கு அனுமதித்தன.

V1-ஐப் பிரித்தெடுத்தல்: ஒரு விலை உயர்ந்த டிஃப் வரியின் செலவு

GitHub-இன் ஆரம்ப React அடிப்படையிலான செயலாக்கம், v1 என குறிப்பிடப்படுகிறது, இது நவீன டிஃப் காட்சிக்கு அடித்தளத்தை அமைத்தது. இந்த பதிப்பு கிளாசிக் Rails காட்சியை React-க்கு மாற்றுவதற்கான ஒரு உண்மையான முயற்சியாகும், சிறிய, மீண்டும் பயன்படுத்தக்கூடிய React கூறுகளை உருவாக்குவதற்கும் ஒரு தெளிவான DOM மர அமைப்பை பராமரிப்பதற்கும் முன்னுரிமை அளித்தது. இருப்பினும், இந்த அணுகுமுறை, அதன் ஆரம்பத்தில் தர்க்கரீதியானதாக இருந்தாலும், அளவில் ஒரு குறிப்பிடத்தக்க இடையூறாக நிரூபிக்கப்பட்டது.

v1-இல், ஒவ்வொரு டிஃப் வரியையும் ரெண்டரிங் செய்வது ஒரு விலை உயர்ந்த செயலாகும். ஒரு ஒருங்கிணைந்த காட்சியில் ஒரு ஒற்றை வரி பொதுவாக சுமார் 10 DOM கூறுகளாக மாற்றப்பட்டது, அதே நேரத்தில் ஒரு ஸ்ப்ளிட் காட்சிக்கு 15-க்கு நெருக்கமானவை தேவைப்பட்டன. இந்த எண்ணிக்கை சின்டாக்ஸ் ஹைலைட்டிங்குடன் மேலும் அதிகரிக்கும், பல <span> டேகுகளை அறிமுகப்படுத்தும். React அடுக்கில், ஒருங்கிணைந்த டிஃப்கள் ஒரு வரிக்கு குறைந்தது எட்டு கூறுகளைக் கொண்டிருந்தன, மற்றும் ஸ்ப்ளிட் காட்சிகள் குறைந்தபட்சம் 13-ஐக் கொண்டிருந்தன. இவை அடிப்படை எண்ணிக்கைகள், கருத்துகள், ஹோவர் மற்றும் ஃபோகஸ் போன்ற கூடுதல் UI நிலைகள் மேலும் பல கூறுகளைச் சேர்த்தன.

v1 கட்டமைப்பு React நிகழ்வு கையாளிகளின் பெருக்கத்தாலும் பாதிக்கப்பட்டது. சிறிய அளவில் பாதிப்பில்லாததாகத் தோன்றினாலும், ஒரு ஒற்றை டிஃப் வரி 20 அல்லது அதற்கு மேற்பட்ட நிகழ்வு கையாளிகளைச் சுமக்க முடியும். ஒரு பெரிய புல் ரிக்வெஸ்ட்டில் ஆயிரக்கணக்கான வரிகளில் பெருக்குகையில், இது விரைவாகக் கூடி, அதிகப்படியான மேல்நிலை செலவு மற்றும் அதிகரித்த JavaScript ஹீப் பயன்பாட்டிற்கு வழிவகுத்தது. இந்த சிக்கலானது செயல்திறனைப் பாதித்தது மட்டுமல்லாமல், மேம்பாடு மற்றும் பராமரிப்பையும் சவாலானதாக மாற்றியது. ஆரம்பகால வடிவமைப்பு, வரையறுக்கப்பட்ட டேட்டாவுக்கு பயனுள்ளதாக இருந்தபோதிலும், GitHub-இன் மாறுபட்ட புல் ரிக்வெஸ்ட் அளவுகளின் வரம்பற்ற தன்மையை எதிர்கொண்டபோது கணிசமாக போராடியது.

சுருக்கமாக, ஒவ்வொரு v1 டிஃப் வரிக்கும், அமைப்பில் இருந்தது:

குறைந்தபட்சம் 10-15 DOM மர கூறுகள்
குறைந்தபட்சம் 8-13 React கூறுகள்
குறைந்தபட்சம் 20 React நிகழ்வு கையாளிகள்
எண்ணற்ற சிறிய, மீண்டும் பயன்படுத்தக்கூடிய React கூறுகள்

இந்த கட்டமைப்பு பெரிய புல் ரிக்வெஸ்ட் அளவுகளுடன் மெதுவான INP மற்றும் அதிகரித்த JavaScript ஹீப் பயன்பாட்டை நேரடியாகத் தொடர்புபடுத்தியது, இது ஒரு அடிப்படை மறு மதிப்பீடு மற்றும் மறுவடிவமைப்பை அவசியமாக்கியது.

ரெண்டரிங்கில் புரட்சி: V2 மேம்பாடுகளின் தாக்கம்

v2-க்கு மாறுதல் ஒரு குறிப்பிடத்தக்க கட்டமைப்பு மறுசீரமைப்பைக் குறித்தது, இது நுட்பமான, தாக்கமான மாற்றங்களில் கவனம் செலுத்தியது. குழு 'செயல்திறனைப் பொறுத்தவரை, குறிப்பாக அளவில், எந்த மாற்றமும் மிகச் சிறியதல்ல' என்ற தத்துவத்தை ஏற்றுக்கொண்டது. ஒரு சிறந்த உதாரணம், வரி எண் செல்களிலிருந்து தேவையற்ற <code> டேகுகளை நீக்கியது. ஒவ்வொரு டிஃப் வரிக்கும் இரண்டு DOM நோடுகளைக் குறைப்பது சிறியதாகத் தோன்றினாலும், 10,000 வரிகளில், இது உடனடியாக DOM-இல் 20,000 குறைவான நோடுகளுக்குச் சமமானது, இது இலக்கு வைக்கப்பட்ட, படிப்படியான மேம்பாடுகள் எவ்வாறு கணிசமான முன்னேற்றங்களை அளிக்கின்றன என்பதைக் காட்டுகிறது.

கீழே உள்ள காட்சி ஒப்பீடு, கூறு மட்டத்தில் v1 இலிருந்து v2 க்கு குறைக்கப்பட்ட சிக்கலைக் காட்டுகிறது:

V1 டிஃப் கூறுகள் மற்றும் HTML. ஒரு ஒற்றை டிஃப் வரிக்கு 8 React கூறுகள் இருந்தன. V2 டிஃப் கூறுகள் மற்றும் HTML. ஒரு ஒற்றை டிஃப் வரிக்கு 3 React கூறுகள் இருந்தன.

சீரமைக்கப்பட்ட கூறு கட்டமைப்பு

v2-இல் ஒரு முக்கிய கண்டுபிடிப்பு கூறு மரத்தை எளிதாக்குவது அடங்கும். குழு ஒவ்வொரு டிஃப் வரிக்கும் எட்டு React கூறுகளிலிருந்து இரண்டாகக் குறைத்தது. ஆழமாக உள்ளமைக்கப்பட்ட கூறு மரங்களை அகற்றுவதன் மூலமும், ஒவ்வொரு ஸ்ப்ளிட் மற்றும் ஒருங்கிணைந்த டிஃப் வரிக்கும் பிரத்யேக கூறுகளை உருவாக்குவதன் மூலமும் இது அடையப்பட்டது. இது சில குறியீடு நகல்களை அறிமுகப்படுத்தியிருந்தாலும், இது டேட்டா அணுகலை கணிசமாக எளிதாக்கியது மற்றும் ஒட்டுமொத்த சிக்கலைக் குறைத்தது. நிகழ்வு கையாளுதலும் மையப்படுத்தப்பட்டது, இப்போது data-attribute மதிப்புகளைப் பயன்படுத்தி ஒரு ஒற்றை மேல்-நிலை கையாளரால் நிர்வகிக்கப்படுகிறது, v1-இன் பல தனிப்பட்ட நிகழ்வு கையாளிகளுக்குப் பதிலாக. இந்த அணுகுமுறை குறியீடு மற்றும் செயல்திறன் இரண்டையும் கணிசமாக சீரமைத்தது.

புத்திசாலித்தனமான நிலை மேலாண்மை மற்றும் O(1) டேட்டா அணுகல்

ஒருவேளை மிகவும் தாக்கமான மாற்றம் கருத்து தெரிவிப்பது மற்றும் சூழல் மெனுக்கள் போன்ற சிக்கலான செயலி நிலையை நிபந்தனைக்குட்பட்டு ரெண்டர் செய்யப்பட்ட குழந்தை கூறுகளுக்கு மாற்றுவதுதான். GitHub போன்ற சூழலில், புல் ரிக்வெஸ்ட்கள் ஆயிரக்கணக்கான வரிகளைத் தாண்டக்கூடிய இடத்தில், ஒரு சிறிய பகுதிக்கு மட்டுமே கருத்துகள் இருக்கும்போது ஒவ்வொரு வரியும் சிக்கலான கருத்துத் தெரிவிக்கும் நிலையைச் சுமப்பது திறமையற்றது. இந்த நிலையை உள்ளமைக்கப்பட்ட கூறுகளுக்கு நகர்த்துவதன் மூலம், டிஃப்-லைன் கூறின் முதன்மைப் பொறுப்பு முற்றிலும் குறியீட்டை ரெண்டரிங் செய்வதாக மாறியது, இது ஒற்றைப் பொறுப்புக் கொள்கையுடன் ஒத்துப்போகிறது.
மேலும், v2 O(n) தேடல்கள் மற்றும் v1-ஐ பாதித்த அதிகப்படியான useEffect ஹூக்குகள் சிக்கலை நிவர்த்தி செய்தது. குழு ஒரு இரண்டு பகுதி மூலோபாயத்தை ஏற்றுக்கொண்டது: useEffect பயன்பாட்டை டிஃப் கோப்புகளின் மேல் மட்டத்திற்கு கடுமையாக கட்டுப்படுத்துதல் மற்றும் வரி-சுற்றும் கூறுகளில் அவற்றின் மறு அறிமுகத்தைத் தடுக்க லிண்டிங் விதிகளை நிறுவுதல். இது துல்லியமான மெமோசைசேஷன் மற்றும் கணிக்கக்கூடிய நடத்தையை உறுதிசெய்தது. அதே நேரத்தில், குளோபல் மற்றும் டிஃப் நிலை இயந்திரங்கள் JavaScript Map பொருள்களைப் பயன்படுத்தி O(1) நிலையான-நேர தேடல்களைப் பயன்படுத்த மறுவடிவமைக்கப்பட்டன. இது வரித் தேர்வு மற்றும் கருத்து மேலாண்மை போன்ற பொதுவான செயல்பாடுகளுக்கு வேகமான, சீரான தேர்வுகளை அனுமதித்தது, குறியீட்டின் தரத்தை கணிசமாக மேம்படுத்தியது, செயல்திறனை மேம்படுத்தியது, மற்றும் தட்டையாக்கப்பட்ட, மேப் செய்யப்பட்ட டேட்டா கட்டமைப்புகளைப் பராமரிப்பதன் மூலம் சிக்கலைக் குறைத்தது. டெவலப்பர் பணிப்பாய்வுகளை மேம்படுத்துவதற்கும் அடிப்படை கட்டமைப்பிற்கும் இந்த உன்னிப்பான அணுகுமுறை ஒரு வலுவான, அளவிடக்கூடிய அமைப்பை உறுதி செய்கிறது.

அளவிடக்கூடிய தாக்கம்: V2 அளவிடக்கூடிய ஆதாயங்களை வழங்குகிறது

v2-இல் செயல்படுத்தப்பட்ட நுட்பமான கட்டமைப்பு மற்றும் குறியீடு-நிலை மேம்பாடுகள் முக்கிய செயல்திறன் மெட்ரிக்ஸ்களில் ஆழமான, அளவிடக்கூடிய முன்னேற்றங்களை அளித்தன. புதிய அமைப்பு கணிசமாக வேகமாக இயங்குகிறது, JavaScript ஹீப் பயன்பாடு மற்றும் INP ஸ்கோர்களில் மிகப்பெரிய குறைப்புடன். ஒரு ஸ்ப்ளிட் டிஃப் அமைப்பில் 10,000 வரி மாற்றங்களைக் கொண்ட ஒரு பிரதிநிதி புல் ரிக்வெஸ்ட்டில் காணப்பட்ட வியத்தகு மேம்பாடுகளை பின்வரும் அட்டவணை காட்டுகிறது:

மெட்ரிக்	v1	v2	மேம்பாடு
JavaScript ஹீப்	1GB+	250MB	75%
DOM நோடுகள்	400,000+	80,000	80%
INP p95	1000ms+	100ms	90%

இந்த புள்ளிவிவரங்கள் GitHub-இன் பலதரப்பட்ட மூலோபாயத்தின் வெற்றியை அடிக்கோடிட்டுக் காட்டுகின்றன. JavaScript ஹீப் அளவில் 75% குறைப்பு மற்றும் DOM நோடுகளில் 80% குறைப்பு ஒரு இலகுவான உலாவி தடயத்திற்கு வழிவகுப்பது மட்டுமல்லாமல், ஒரு நிலையான மற்றும் பதிலளிக்கக்கூடிய இடைமுகத்திற்கும் நேரடியாக பங்களிக்கிறது. மிகவும் குறிப்பிடத்தக்க மேம்பாடு, INP p95-இல் 90% குறைப்பு (இடைவினை தாமதத்தின் 95வது சதவீதம்), அதாவது 95% பயனர் இடைவினைகள் இப்போது வெறும் 100 மில்லி வினாடிகளுக்குள் நிறைவடைகின்றன, v1-இல் பெரிய புல் ரிக்வெஸ்ட்களைப் பாதித்த உள்ளீட்டு தாமதத்தை கிட்டத்தட்ட நீக்குகிறது. இது பயனர் அனுபவத்தை கணிசமாக மேம்படுத்துகிறது, பெரிய குறியீடு மதிப்பாய்வுகளை சிறியவற்றைப் போலவே திரவமாகவும் பதிலளிக்கக்கூடியதாகவும் உணர வைக்கிறது.

டிஃப்-லைன் மேம்பாட்டில் இந்த ஆழமான ஆய்வு மூலம் நிரூபிக்கப்பட்ட GitHub-இன் தொடர்ச்சியான மேம்பாட்டிற்கான அர்ப்பணிப்பு, உலகத் தரம் வாய்ந்த டெவலப்பர் தளத்தை வழங்குவதற்கான அவர்களின் உறுதிப்பாட்டிற்கு ஒரு சான்றாகும். செயல்திறன் இடையூறுகளை தீவிரமாக பகுப்பாய்வு செய்து இலக்கு வைக்கப்பட்ட கட்டமைப்பு தீர்வுகளை செயல்படுத்துவதன் மூலம், அவர்கள் முக்கியமான அளவிடல் சிக்கல்களைத் தீர்த்தது மட்டுமல்லாமல், தங்கள் முக்கிய தயாரிப்பில் பதிலளிக்கக்கூடிய தன்மைக்கு ஒரு புதிய தரத்தையும் நிர்ணயித்துள்ளனர். செயல்திறனில் இந்த கவனம், பொறியியலாளர்கள் குறியீடு மதிப்பாய்வுகள் போன்ற முக்கியமான பணிகளில் திறம்பட ஈடுபடுவதை உறுதிசெய்கிறது, இது இறுதியில் உயர்ந்த குறியீடு தரம் மற்றும் பாதுகாப்பிற்கும் மேலும் உற்பத்தித்திறன் மிக்க மேம்பாட்டு சூழலுக்கும் வழிவகுக்கிறது.

அசல் மூலம்

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

அடிக்கடி கேட்கப்படும் கேள்விகள்

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.

புதுப்பிப்புகளைப் பெறுங்கள்

சமீபத்திய AI செய்திகளை மின்னஞ்சலில் பெறுங்கள்.

பகிர்