أداء خطوط الاختلاف (Diff Lines): صعود GitHub الشاق نحو التحسين

صعود GitHub الشاق: تحسين خطوط الاختلاف لأقصى أداء

تعد طلبات السحب جوهر GitHub النابض بالحياة، حيث يكرس عدد لا يحصى من المهندسين جزءًا كبيرًا من حياتهم المهنية. نظرًا لحجم GitHub الهائل، والتعامل مع طلبات السحب التي تتراوح من الإصلاحات الطفيفة لسطر واحد إلى التغييرات الهائلة التي تمتد لآلاف الملفات وملايين الأسطر، يجب أن تظل تجربة المراجعة سريعة الاستجابة بشكل استثنائي. لقد كان الإطلاق الأخير لتجربة جديدة قائمة على React لعلامة التبويب الملفات المتغيرة، وهي الآن الافتراضية لجميع المستخدمين، استثمارًا محوريًا في ضمان الأداء القوي، خاصة لطلبات السحب الكبيرة الصعبة هذه. تضمن هذا الالتزام المعالجة المستمرة للمشكلات الصعبة مثل العرض الأمثل وزمن استجابة التفاعل واستهلاك الذاكرة.

قبل هذه التحسينات، بينما استمتع معظم المستخدمين بتجربة سريعة الاستجابة، أدت طلبات السحب الكبيرة حتمًا إلى تدهور ملحوظ في الأداء. وشهدت الحالات القصوى تجاوز ذاكرة كومة JavaScript 1 جيجابايت، وتجاوز عدد عقد DOM 400,000، وأصبحت تفاعلات الصفحة بطيئة للغاية أو حتى غير قابلة للاستخدام. ارتفعت مقاييس الاستجابة الرئيسية مثل التفاعل إلى عرض الطلاء التالي (INP) فوق المستويات المقبولة، مما خلق إحساسًا ملموسًا بتأخير الإدخال للمستخدمين. تتعمق هذه المقالة في الرحلة التفصيلية التي خاضتها GitHub لتحسين مقاييس الأداء الأساسية هذه بشكل كبير، مما أدى إلى تحويل تجربة مراجعة الاختلافات.

التنقل في اختناقات الأداء: نهج متعدد الاستراتيجيات

عند بدء التحقيق في أداء علامة التبويب الملفات المتغيرة، سرعان ما أصبح واضحًا أن حل 'الطلقة الفضية' الواحدة لن يكون كافيًا. غالبًا ما وصلت التقنيات المصممة للحفاظ على كل ميزة وسلوك متصفح أصلي إلى سقفها مع أحمال البيانات القصوى. وعلى العكس من ذلك، فإن التخفيفات التي تهدف فقط إلى منع أسوأ السيناريوهات قد تقدم مفاضلات غير مواتية للمراجعات اليومية.

بدلاً من ذلك، طور فريق الهندسة في GitHub مجموعة شاملة من الاستراتيجيات، صُممت كل منها بدقة لمعالجة أحجام وتعقيدات طلبات السحب المحددة. بُنيت هذه الاستراتيجيات على ثلاثة محاور أساسية:

تحسينات مركزة لمكونات خطوط الاختلاف: تعزيز كفاءة تجربة الاختلاف الأساسية لغالبية طلبات السحب. هذا يضمن بقاء المراجعات المتوسطة والكبيرة سريعة دون المساس بالوظائف المتوقعة مثل البحث الأصلي في الصفحة.
تقليل الأداء بلطف باستخدام الافتراضية: ضمان قابلية الاستخدام لأكبر طلبات السحب من خلال إعطاء الأولوية للاستجابة والاستقرار، والحد بذكاء مما يتم عرضه في أي لحظة معينة.
الاستثمار في المكونات الأساسية وتحسينات العرض: تنفيذ تحسينات تحقق فوائد متراكمة عبر كل حجم طلب سحب، بغض النظر عن وضع عرض المستخدم المحدد.

وجهت هذه الركائز الاستراتيجية جهود الفريق، مما سمح لهم بمعالجة الأسباب الجذرية لمشكلات الأداء بشكل منهجي وتمهيد الطريق للتحسينات المعمارية اللاحقة.

تفكيك الإصدار الأول (V1): تكلفة سطر الاختلاف المكلف

وضع التنفيذ الأولي لـ GitHub القائم على React، والمشار إليه باسم الإصدار الأول (v1)، الأساس لعرض الاختلافات الحديث. كانت هذه النسخة جهدًا جادًا لنقل عرض Rails الكلاسيكي إلى React، مع إعطاء الأولوية لإنشاء مكونات React صغيرة قابلة لإعادة الاستخدام والحفاظ على هيكل شجرة DOM واضح. ومع ذلك، أثبت هذا النهج، رغم كونه منطقيًا في بدايته، أنه يمثل عنق الزجاجة كبيرًا عند التوسع.

في الإصدار الأول، كان عرض كل سطر اختلاف عملية مكلفة. عادة ما يترجم السطر الواحد في عرض موحد إلى حوالي 10 عناصر DOM، بينما يتطلب العرض المقسم ما يقرب من 15. سيزداد هذا العدد بشكل أكبر مع تسليط الضوء على بناء الجملة (syntax highlighting)، مما يقدم العديد من علامات <span> الإضافية. على طبقة React، احتوت الاختلافات الموحدة على ثمانية مكونات على الأقل لكل سطر، والعروض المقسمة على 13 مكونًا كحد أدنى. كانت هذه أعدادًا أساسية، مع حالات واجهة مستخدم إضافية مثل التعليقات، والتمرير، والتركيز، مما يضيف المزيد من المكونات.

كما عانت بنية الإصدار الأول من انتشار معالجات أحداث React. فبينما تبدو غير ضارة على نطاق صغير، يمكن لسطر اختلاف واحد أن يحمل 20 معالج أحداث أو أكثر. وعند ضرب هذا العدد عبر آلاف الأسطر في طلب سحب كبير، يتراكم هذا بسرعة، مما يؤدي إلى نفقات إضافية مفرطة وزيادة في استخدام ذاكرة كومة JavaScript. لم يؤثر هذا التعقيد على الأداء فحسب، بل جعل التطوير والصيانة أكثر صعوبة أيضًا. التصميم الأولي، الفعال للبيانات المحدودة، كافح بشكل كبير عندما واجه الطبيعة غير المحدودة لأحجام طلبات السحب المتنوعة في GitHub.

باختصار، لكل سطر اختلاف في الإصدار الأول، كان النظام يحتوي على:

ما لا يقل عن 10-15 عنصرًا من شجرة DOM
ما لا يقل عن 8-13 مكونًا من مكونات React
ما لا يقل عن 20 معالج أحداث React
عدد كبير من مكونات React الصغيرة القابلة لإعادة الاستخدام

ربطت هذه البنية بشكل مباشر أحجام طلبات السحب الأكبر بتباطؤ INP وزيادة استخدام ذاكرة كومة JavaScript، مما استلزم إعادة تقييم وإعادة تصميم أساسيين.

إحداث ثورة في العرض: تأثير تحسينات الإصدار الثاني (V2)

شكل الانتقال إلى الإصدار الثاني (v2) تحولًا معماريًا كبيرًا، مع التركيز على التغييرات الدقيقة والمؤثرة. تبنى الفريق الفلسفة القائلة بأن "لا يوجد تغيير صغير جدًا عندما يتعلق الأمر بالأداء، خاصة على نطاق واسع." وكان أحد الأمثلة الرئيسية هو إزالة علامات <code> غير الضرورية من خلايا أرقام الأسطر. فبينما قد يبدو إسقاط عقدتي DOM لكل سطر اختلاف أمرًا بسيطًا، إلا أنه عبر 10,000 سطر، يعادل هذا فورًا 20,000 عقدة أقل في DOM، مما يوضح كيف تؤدي التحسينات المستهدفة التدريجية إلى تحسينات جوهرية.

يوضح التباين البصري أدناه التعقيد المخفض من الإصدار الأول إلى الإصدار الثاني على مستوى المكونات:

V1 Diff Components and HTML. We had 8 react components for a single diff line. مكونات الإصدار الأول (V1) لخطوط الاختلاف وHTML. كان لدينا 8 مكونات React لسطر اختلاف واحد. V2 Diff Components and HTML. We had 3 react components for a single diff line. مكونات الإصدار الثاني (V2) لخطوط الاختلاف وHTML. كان لدينا 3 مكونات React لسطر اختلاف واحد.

بنية المكونات المبسّطة

تمثلت إحدى الابتكارات الأساسية في الإصدار الثاني (v2) في تبسيط شجرة المكونات. انتقل الفريق من ثمانية مكونات React لكل سطر اختلاف إلى مكونين. وقد تحقق ذلك عن طريق إزالة أشجار المكونات المتداخلة بعمق وإنشاء مكونات مخصصة لكل سطر اختلاف مقسم وموحد. ورغم أن هذا أدى إلى بعض تكرار التعليمات البرمجية، إلا أنه بسّط الوصول إلى البيانات بشكل كبير وقلل التعقيد الكلي. كما تم مركزة معالجة الأحداث، وأصبحت الآن تُدار بواسطة معالج واحد على المستوى الأعلى يستخدم قيم data-attribute، ليحل محل معالجات الأحداث الفردية العديدة في الإصدار الأول. هذا النهج بسّط كل من التعليمات البرمجية والأداء بشكل جذري.

إدارة الحالة الذكية والوصول إلى البيانات بزمن ثابت O(1)

ربما كان التغيير الأكثر تأثيرًا هو نقل حالة التطبيق المعقدة، مثل التعليق وقوائم السياق، إلى مكونات فرعية يتم عرضها بشكل شرطي. في بيئة مثل GitHub، حيث يمكن أن تتجاوز طلبات السحب آلاف الأسطر، من غير الفعال أن يحمل كل سطر حالة تعليق معقدة بينما جزء صغير فقط هو الذي سيكون لديه تعليقات على الإطلاق. بنقل هذه الحالة إلى مكونات متداخلة، أصبحت المسؤولية الأساسية لمكون سطر الاختلاف هي عرض التعليمات البرمجية بحتة، مما يتوافق مع مبدأ المسؤولية الواحدة.

علاوة على ذلك، عالج الإصدار الثاني مشكلة عمليات البحث من نوع O(n) وخطافات useEffect المفرطة التي عانت منها v1. تبنى الفريق استراتيجية من جزأين: تقييد استخدام useEffect بشكل صارم على المستوى الأعلى لملفات الاختلاف وإنشاء قواعد linting لمنع إعادة تقديمها في مكونات التفاف الأسطر. وقد ضمن ذلك التخزين المؤقت الدقيق والسلوك المتوقع. في الوقت نفسه، أعيد تصميم آلات حالة الاختلاف والحالة العالمية للاستفادة من عمليات البحث بزمن ثابت O(1) باستخدام كائنات JavaScript Map. وقد سمح ذلك بمحددات سريعة ومتسقة للعمليات الشائعة مثل تحديد الأسطر وإدارة التعليقات، مما عزز بشكل كبير جودة التعليمات البرمجية، وحسّن الأداء، وقلل التعقيد عن طريق الحفاظ على هياكل بيانات مسطحة ومحددة. يضمن هذا النهج الدقيق لتحسين سير عمل المطورين والبنية التحتية نظامًا قويًا وقابلاً للتوسع.

التأثير القابل للقياس: الإصدار الثاني (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% لا يترجم فقط إلى بصمة متصفح أخف، بل يساهم أيضًا بشكل مباشر في واجهة أكثر استقرارًا واستجابة. التحسن الأكثر إبهارًا، وهو تخفيض بنسبة 90% في INP p95 (الشريحة المئوية الخامسة والتسعون لزمن استجابة التفاعل)، يعني أن 95% من تفاعلات المستخدم تكتمل الآن في غضون 100 مللي ثانية فقط، مما يزيل عمليًا تأخر الإدخال الذي ابتليت به طلبات السحب الكبيرة في الإصدار الأول. يعزز هذا بشكل كبير تجربة المستخدم، مما يجعل مراجعات التعليمات البرمجية الكبيرة تبدو سلسة ومستجيبة مثل المراجعات الأصغر.

إن التزام 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.

ابقَ على اطلاع

احصل على آخر أخبار الذكاء الاصطناعي في بريدك.