title: "डिफ लाइनों का प्रदर्शन: GitHub का अनुकूलन का कठिन चढ़ाई" slug: "the-uphill-climb-of-making-diff-lines-performant" date: "2026-04-06" lang: "hi" source: "https://github.blog/engineering/architecture-optimization/the-uphill-climb-of-making-diff-lines-performant/" category: "डेवलपर उपकरण" keywords:
- GitHub
- पुल रिक्वेस्ट
- प्रदर्शन अनुकूलन
- डिफ लाइनें
- React विकास
- वेब प्रदर्शन
- DOM अनुकूलन
- JavaScript हीप
- इंटरैक्शन टू नेक्स्ट पेंट (INP)
- सॉफ्टवेयर आर्किटेक्चर
- घटक डिजाइन
- फ्रंट-एंड इंजीनियरिंग meta_description: 'GitHub की इंजीनियरिंग टीम पुल रिक्वेस्ट में डिफ लाइन परफॉर्मेंस को ऑप्टिमाइज़ करने की अपनी कठोर यात्रा का विवरण देती है, जिससे जावास्क्रिप्ट हीप, DOM नोड्स में उल्लेखनीय कमी आती है और INP में सुधार होता है।' image: "/images/articles/the-uphill-climb-of-making-diff-lines-performant.png" image_alt: 'GitHub डिफ लाइनों में प्रदर्शन सुधार को दर्शाने वाला आरेख, एक अनुकूलित दृश्य में कम किए गए DOM नोड्स और जावास्क्रिप्ट हीप को उजागर करता है।' quality_score: 94 content_score: 93 seo_score: 95 companies:
- GitHub schema_type: "NewsArticle" reading_time: 7 faq:
- question: "GitHub पुल रिक्वेस्ट में 'Files changed' टैब क्या है और इसका प्रदर्शन इतना महत्वपूर्ण क्यों था?" answer: 'Files changed'' टैब GitHub के पुल रिक्वेस्ट वर्कफ़्लो का एक मुख्य घटक है, जो इंजीनियरों को कोड संशोधनों की समीक्षा करने की अनुमति देता है। इसका प्रदर्शन महत्वपूर्ण है क्योंकि डेवलपर्स यहीं पर महत्वपूर्ण समय बिताते हैं, और धीमापन, विशेष रूप से बड़ी पुल रिक्वेस्ट के साथ, उत्पादकता और उपयोगकर्ता अनुभव को गंभीर रूप से बाधित कर सकता है। GitHub ने कोड परिवर्तनों के सभी पैमानों पर प्रतिक्रियाशीलता सुनिश्चित करने के लिए इसके अनुकूलन को प्राथमिकता दी, छोटे सुधारों से लेकर व्यापक रिफैक्टरिंग तक, जिसमें हजारों फ़ाइलों में लाखों लाइनें शामिल हो सकती हैं। एक सुगम और कुशल समीक्षा प्रक्रिया बनाए रखना सहयोगात्मक विकास के लिए सर्वोपरि है।'
- question: "v1 आर्किटेक्चर में बड़ी पुल रिक्वेस्ट के साथ GitHub को किन प्राथमिक प्रदर्शन चुनौतियों का सामना करना पड़ा?" answer: 'अपने प्रारंभिक React-आधारित आर्किटेक्चर (v1) में, GitHub को बड़ी पुल रिक्वेस्ट को संभालते समय महत्वपूर्ण प्रदर्शन गिरावट का सामना करना पड़ा। मुख्य मुद्दों में 1 GB से अधिक JavaScript हीप, 400,000 से अधिक DOM नोड काउंट और पेज इंटरैक्शन का अत्यधिक धीमा या अनुपयोगी होना शामिल था। इंटरैक्शन टू नेक्स्ट पेंट (INP) मेट्रिक, जो प्रतिक्रियाशीलता को मापता है, ने अस्वीकार्य रूप से उच्च मान दिखाए। ये समस्याएं एक अक्षम रेंडरिंग रणनीति से उत्पन्न हुई थीं जहाँ प्रत्येक डिफ लाइन संसाधन-गहन थी, जिसमें बहुत सारे DOM तत्व, React घटक और इवेंट हैंडलर थे, विशेष रूप से हजारों लाइनों के कोड वाले मामलों में।'
- question: "'सिल्वर बुलेट' समाधान से आगे बढ़ते हुए, GitHub ने जटिल प्रदर्शन समस्याओं को हल करने के लिए कैसे दृष्टिकोण अपनाया?" answer: 'यह पहचानते हुए कि कोई भी एक समाधान पुल रिक्वेस्ट के विविध आकार और जटिलताओं को संबोधित नहीं करेगा, GitHub ने एक बहु-आयामी रणनीतिक दृष्टिकोण अपनाया। उन्होंने तीन मुख्य विषयों पर ध्यान केंद्रित किया: डिफ-लाइन घटकों के लिए लक्षित अनुकूलन ताकि मध्यम और बड़ी समीक्षाओं को तेज़ रखा जा सके, सबसे बड़ी पुल रिक्वेस्ट के लिए रेंडर की गई सामग्री को सीमित करके उपयोगिता बनाए रखने के लिए वर्चुअलाइजेशन के साथ अनुग्रही गिरावट, और सभी पुल रिक्वेस्ट आकारों में संचयी लाभ प्राप्त करने के लिए मूलभूत घटकों और रेंडरिंग सुधारों में निवेश करना। इस व्यापक रणनीति ने उन्हें विशिष्ट समस्या क्षेत्रों के अनुरूप समाधान तैयार करने की अनुमति दी।'
- question: "'v1' डिफ रेंडरिंग आर्किटेक्चर की मुख्य सीमाएँ क्या थीं, जिन्होंने इसे स्केल के लिए अस्थिर बना दिया?"
answer: 'v1 आर्किटेक्चर, जबकि छोटे डिफ्स के लिए शुरू में समझदार था, बड़े पैमाने पर पुल रिक्वेस्ट के लिए अस्थिर साबित हुआ। प्रत्येक डिफ लाइन महंगी थी, जिसमें 10-15 DOM तत्वों, 8-13 React घटकों और 20 से अधिक इवेंट हैंडलर की आवश्यकता होती थी। यह गहरी घटक नेस्टिंग, अत्यधिक
useEffectहुक्स और O(n) डेटा लुकअप द्वारा जटिल था, जिससे अनावश्यक री-रेंडर और बढ़ी हुई जटिलता हुई। एब्स्ट्रैक्शन परतें, कोड साझा करने के लिए थीं, अनजाने में ओवरहेड जोड़ा, दोनों स्प्लिट और यूनिफाइड दृश्यों के लिए तर्क ले जाकर, भले ही केवल एक सक्रिय था। इस डिज़ाइन के कारण बड़े डिफ्स के लिए JavaScript हीप, DOM काउंट और खराब INP स्कोर में उल्लेखनीय वृद्धि हुई।' - question: "'v2' में डिफ लाइन प्रदर्शन में नाटकीय रूप से सुधार के लिए कौन से विशिष्ट स्थापत्य परिवर्तन लागू किए गए थे?"
answer: 'v2 आर्किटेक्चर ने कई महत्वपूर्ण परिवर्तन पेश किए। इसने घटक ट्री को सुव्यवस्थित किया, प्रति डिफ लाइन React घटकों को आठ से दो तक कम कर दिया, स्प्लिट और यूनिफाइड दृश्यों के लिए समर्पित घटक बनाकर, कुछ कोड डुप्लीकेशन के साथ भी। इवेंट हैंडलिंग को
data-attributeमानों का उपयोग करके एक एकल शीर्ष-स्तरीय हैंडलर में केंद्रीकृत किया गया था, जिससे कई व्यक्तिगत हैंडलर बदल गए। जटिल ऐप स्थिति, जैसे टिप्पणी सुविधाएँ, सशर्त रूप से रेंडर किए गए चाइल्ड घटकों में ले जाया गया था, यह सुनिश्चित करते हुए कि डिफ लाइनें मुख्य रूप से कोड रेंडर करने पर केंद्रित थीं। इसके अलावा, v2 नेuseEffectहुक्स को शीर्ष-स्तरीय डिफ फ़ाइलों तक सीमित कर दिया और कुशल स्थिति लुकअप के लिएJavaScript Mapका उपयोग करके O(1) स्थिर-समय डेटा एक्सेस को अपनाया, जिससे री-रेंडर में उल्लेखनीय कमी आई और डेटा प्रबंधन में सुधार हुआ।' - question: "GitHub इंजीनियरिंग टीम ने v2 के साथ JavaScript हीप, DOM नोड्स और INP मेट्रिक्स में मात्रात्मक सुधार कैसे प्राप्त किए?" answer: 'v2 के स्थापत्य परिवर्तनों के संचयी प्रभाव से पर्याप्त मात्रात्मक सुधार हुए। 10,000 लाइन परिवर्तनों वाली पुल रिक्वेस्ट के लिए, JavaScript हीप का आकार 1GB+ से घटाकर 250MB कर दिया गया, जो 75% सुधार है। DOM नोड्स 400,000+ से घटकर 80,000 हो गए, जो 80% की कमी है। इंटरैक्शन टू नेक्स्ट पेंट (INP) p95 (95वां परसेंटाइल) में आश्चर्यजनक 90% सुधार देखा गया, जो 1000ms+ से घटकर केवल 100ms हो गया। ये परिणाम सावधानीपूर्वक अनुकूलन के माध्यम से प्राप्त किए गए, जिसमें बाहरी DOM तत्वों को हटाना, React घटक संरचना को सरल बनाना, इवेंट हैंडलिंग को केंद्रीकृत करना और स्थिति प्रबंधन व डेटा एक्सेस पैटर्न को अनुकूलित करना शामिल था, जिससे एक बहुत तेज़ और अधिक प्रतिक्रियाशील उपयोगकर्ता अनुभव प्राप्त हुआ।'
- question: "इंटरैक्शन टू नेक्स्ट पेंट (INP) क्या है और GitHub के उपयोगकर्ता अनुभव के लिए इसका सुधार महत्वपूर्ण क्यों है?" answer: 'इंटरैक्शन टू नेक्स्ट पेंट (INP) एक महत्वपूर्ण वेब प्रदर्शन मेट्रिक है जो उपयोगकर्ता द्वारा पेज के साथ की गई सभी इंटरैक्शन की विलंबता को मापकर पेज की प्रतिक्रियाशीलता का आकलन करता है। यह उस समय को रिकॉर्ड करता है जब कोई उपयोगकर्ता इंटरैक्ट करता है (जैसे क्लिक, टैप, कीप्रेस) जब तक अगला फ़्रेम स्क्रीन पर पेंट नहीं हो जाता, उस इंटरैक्शन की दृश्य प्रतिक्रिया को दर्शाता है। GitHub के लिए, एक उच्च INP का मतलब था कि उपयोगकर्ताओं को ध्यान देने योग्य इनपुट लैग का अनुभव हुआ, जिससे प्लेटफ़ॉर्म धीमा और अनुत्तरदायी महसूस हुआ। v2 में INP p95 को 1000ms से घटाकर 100ms करके, GitHub ने 'Files changed' टैब की कथित गति और तरलता को काफी बढ़ाया, जिससे एक सहज और अधिक संतोषजनक डेवलपर अनुभव सुनिश्चित हुआ, खासकर कोड समीक्षा के दौरान।'
## GitHub का कठिन चढ़ाई: अधिकतम प्रदर्शन के लिए डिफ लाइनों का अनुकूलन
पुल रिक्वेस्ट GitHub का जीवंत केंद्र हैं, जहाँ अनगिनत इंजीनियर अपने पेशेवर जीवन का एक महत्वपूर्ण हिस्सा समर्पित करते हैं। GitHub के विशाल पैमाने को देखते हुए, पुल रिक्वेस्ट को संभालना, जो छोटे एक-लाइन सुधारों से लेकर हजारों फ़ाइलों और लाखों लाइनों में फैले विशाल परिवर्तनों तक होते हैं, समीक्षा अनुभव असाधारण रूप से तेज़ और प्रतिक्रियाशील बना रहना चाहिए। **Files changed** टैब के लिए नए React-आधारित अनुभव का हालिया रोलआउट, जो अब सभी उपयोगकर्ताओं के लिए डिफ़ॉल्ट है, मजबूत प्रदर्शन सुनिश्चित करने में एक महत्वपूर्ण निवेश का प्रतीक था, विशेष रूप से इन चुनौतीपूर्ण बड़ी पुल रिक्वेस्ट के लिए। इस प्रतिबद्धता में अनुकूलित रेंडरिंग, इंटरैक्शन विलंबता और मेमोरी खपत जैसी कठिन समस्याओं को लगातार हल करना शामिल था।
इन अनुकूलनों से पहले, जबकि अधिकांश उपयोगकर्ता एक प्रतिक्रियाशील अनुभव का आनंद लेते थे, बड़ी पुल रिक्वेस्ट अनिवार्य रूप से प्रदर्शन में गिरावट का कारण बनती थीं। अत्यधिक मामलों में जावास्क्रिप्ट हीप 1 GB से अधिक हो जाता था, DOM नोड काउंट 400,000 से अधिक हो जाते थे, और पेज इंटरैक्शन अत्यधिक धीमा या अनुपयोगी हो जाता था। [Interaction to Next Paint (INP)](https://web.dev/articles/inp#what-is-inp) जैसे मुख्य प्रतिक्रियाशीलता मेट्रिक्स स्वीकार्य स्तरों से ऊपर बढ़ गए, जिससे उपयोगकर्ताओं के लिए इनपुट लैग का एक मूर्त अहसास हुआ। यह लेख GitHub द्वारा इन मुख्य प्रदर्शन मेट्रिक्स में नाटकीय रूप से सुधार करने के लिए की गई विस्तृत यात्रा की पड़ताल करता है, जिससे डिफ समीक्षा अनुभव बदल गया।
## प्रदर्शन बाधाओं को नेविगेट करना: एक बहु-रणनीति दृष्टिकोण
जब **Files changed** टैब के लिए प्रदर्शन जांच शुरू की गई, तो यह तुरंत स्पष्ट हो गया कि एक "सिल्वर बुलेट" समाधान पर्याप्त नहीं होगा। प्रत्येक सुविधा और ब्राउज़र-नेटिव व्यवहार को संरक्षित करने के लिए डिज़ाइन की गई तकनीकें अक्सर अत्यधिक डेटा लोड के साथ एक सीमा पर पहुँच जाती हैं। इसके विपरीत, केवल सबसे खराब स्थिति को रोकने के उद्देश्य से किए गए शमन दैनिक समीक्षाओं के लिए प्रतिकूल व्यापार-बंद पेश कर सकते हैं।
इसके बजाय, GitHub की इंजीनियरिंग टीम ने रणनीतियों का एक व्यापक सेट विकसित किया, प्रत्येक को विशिष्ट पुल रिक्वेस्ट आकारों और जटिलताओं को संबोधित करने के लिए सावधानीपूर्वक डिज़ाइन किया गया। ये रणनीतियाँ तीन मुख्य विषयों पर आधारित थीं:
1. **डिफ-लाइन घटकों के लिए केंद्रित अनुकूलन:** अधिकांश पुल रिक्वेस्ट के लिए प्राथमिक डिफ अनुभव की दक्षता बढ़ाना। इसने सुनिश्चित किया कि मध्यम और बड़ी समीक्षाएँ मूल पेज में खोज जैसी अपेक्षित कार्यक्षमताओं से समझौता किए बिना तेज़ बनी रहें।
2. **वर्चुअलाइजेशन के साथ अनुग्रही गिरावट:** सबसे बड़ी पुल रिक्वेस्ट के लिए उपयोगिता सुनिश्चित करना, प्रतिक्रियाशीलता और स्थिरता को प्राथमिकता देना, और किसी भी समय रेंडर की गई सामग्री को बुद्धिमानी से सीमित करना।
3. **मूल घटकों और रेंडरिंग सुधारों में निवेश:** ऐसे सुधारों को लागू करना जो उपयोगकर्ता के विशिष्ट देखने के मोड की परवाह किए बिना, प्रत्येक पुल रिक्वेस्ट आकार में संचयी लाभ प्रदान करते हैं।
इन रणनीतिक स्तंभों ने टीम के प्रयासों का मार्गदर्शन किया, जिससे उन्हें प्रदर्शन समस्याओं के मूल कारणों को व्यवस्थित रूप से हल करने और बाद के स्थापत्य शोधन के लिए मंच तैयार करने की अनुमति मिली।
## 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 तक कम हुई जटिलता को उजागर करता है:
### सुव्यवस्थित घटक आर्किटेक्चर
v2 में एक मुख्य नवाचार में घटक ट्री को सरल बनाना शामिल था। टीम प्रति डिफ लाइन आठ React घटकों से दो तक चली गई। यह गहरी नेस्टेड घटक ट्री को हटाकर और प्रत्येक स्प्लिट और यूनिफाइड डिफ लाइन के लिए समर्पित घटक बनाकर हासिल किया गया था, कुछ कोड डुप्लीकेशन के साथ भी। इवेंट हैंडलिंग को भी केंद्रीकृत किया गया था, अब `data-attribute` मानों का उपयोग करके एक एकल शीर्ष-स्तरीय हैंडलर द्वारा प्रबंधित किया जाता है, जो v1 के कई व्यक्तिगत इवेंट हैंडलर को बदल देता है। इस दृष्टिकोण ने कोड और प्रदर्शन दोनों को नाटकीय रूप से सुव्यवस्थित किया।
### इंटेलिजेंट स्टेट मैनेजमेंट और O(1) डेटा एक्सेस
शायद सबसे प्रभावशाली परिवर्तन जटिल ऐप स्थिति, जैसे टिप्पणी और संदर्भ मेनू, को सशर्त रूप से रेंडर किए गए चाइल्ड घटकों में स्थानांतरित करना था। GitHub जैसे वातावरण में, जहाँ पुल रिक्वेस्ट हजारों लाइनों से अधिक हो सकती हैं, प्रत्येक लाइन के लिए जटिल टिप्पणी स्थिति को ले जाना अक्षम है जब केवल एक छोटा अंश ही कभी टिप्पणियाँ रखेगा। इस स्थिति को नेस्टेड घटकों में स्थानांतरित करके, डिफ-लाइन घटक की प्राथमिक जिम्मेदारी विशुद्ध रूप से कोड रेंडर करना बन गई, जो एकल जिम्मेदारी सिद्धांत के अनुरूप है।
इसके अलावा, v2 ने O(n) लुकअप और अत्यधिक `useEffect` हुक्स के मुद्दे को संबोधित किया जिसने v1 को परेशान किया था। टीम ने एक दो-भाग रणनीति अपनाई: `useEffect` उपयोग को डिफ फ़ाइलों के शीर्ष स्तर तक सख्ती से प्रतिबंधित करना और लाइन-रैपिंग घटकों में उनके पुन: परिचय को रोकने के लिए लिंटिंग नियम स्थापित करना। इसने सटीक मेमोराइजेशन और अनुमानित व्यवहार सुनिश्चित किया। साथ ही, वैश्विक और डिफ स्टेट मशीनों को JavaScript `Map` वस्तुओं का उपयोग करके O(1) स्थिर-समय लुकअप का लाभ उठाने के लिए फिर से डिज़ाइन किया गया। इसने लाइन चयन और टिप्पणी प्रबंधन जैसे सामान्य कार्यों के लिए तेज़, सुसंगत चयनकर्ताओं की अनुमति दी, जिससे कोड की गुणवत्ता में काफी वृद्धि हुई, प्रदर्शन में सुधार हुआ, और चपटी, मैप की गई डेटा संरचनाओं को बनाए रखते हुए जटिलता कम हुई। [डेवलपर वर्कफ़्लो को अनुकूलित करने](/hi/github-agentic-workflows) और अंतर्निहित आर्किटेक्चर के लिए यह सावधानीपूर्वक दृष्टिकोण एक मजबूत, स्केलेबल सिस्टम सुनिश्चित करता है।
## औसत दर्जे का प्रभाव: V2 मात्रात्मक लाभ प्रदान करता है
v2 में लागू किए गए सावधानीपूर्वक स्थापत्य और कोड-स्तर के अनुकूलनों ने प्रमुख प्रदर्शन मेट्रिक्स में गहन, मात्रात्मक सुधार किए। नई प्रणाली काफी तेज़ चलती है, जिसमें जावास्क्रिप्ट हीप उपयोग और 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 (इंटरैक्शन विलंबता का 95वां परसेंटाइल) में 90% की कमी, का अर्थ है कि 95% उपयोगकर्ता इंटरैक्शन अब केवल 100 मिलीसेकंड के भीतर पूरे हो जाते हैं, वस्तुतः इनपुट लैग को समाप्त कर दिया गया है जिसने v1 में बड़ी पुल रिक्वेस्ट को परेशान किया था। यह उपयोगकर्ता अनुभव को महत्वपूर्ण रूप से बढ़ाता है, जिससे बड़ी कोड समीक्षाएँ छोटी समीक्षाओं के समान तरल और प्रतिक्रियाशील महसूस होती हैं।
सतत सुधार के लिए GitHub की प्रतिबद्धता, डिफ-लाइन अनुकूलन में इस गहन जानकारी से स्पष्ट है, एक विश्व-स्तरीय डेवलपर प्लेटफ़ॉर्म प्रदान करने के लिए उनके समर्पण का एक वसीयतनामा है। प्रदर्शन बाधाओं का कठोरता से विश्लेषण करके और लक्षित स्थापत्य समाधानों को लागू करके, उन्होंने न केवल महत्वपूर्ण स्केलेबिलिटी मुद्दों को हल किया है, बल्कि अपने मुख्य उत्पाद में प्रतिक्रियाशीलता के लिए एक नया मानक भी स्थापित किया है। प्रदर्शन पर यह ध्यान सुनिश्चित करता है कि इंजीनियर कोड समीक्षा जैसे महत्वपूर्ण कार्यों में कुशलता से संलग्न हो सकते हैं, जिससे अंततः उच्च [कोड गुणवत्ता और सुरक्षा](/hi/how-to-scan-for-vulnerabilities-with-github-security-labs-open-source-ai-powered-framework) और एक अधिक उत्पादक विकास वातावरण प्राप्त होता है।
अक्सर पूछे जाने वाले प्रश्न
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 समाचार अपने इनबॉक्स में पाएं।