Diff Satırları Performansı: GitHub'ın Optimize Etmek İçin Yokuş Yukarı Mücadelesi

GitHub'ın Yokuş Yukarı Mücadelesi: Diff Satırlarını En Yüksek Performans İçin Optimize Etmek

Çekme istekleri, sayısız mühendisin profesyonel yaşamlarının önemli bir bölümünü adadığı GitHub'ın canlı çekirdeğini oluşturur. GitHub'ın muazzam ölçeği göz önüne alındığında, küçük tek satırlık düzeltmelerden binlerce dosyayı ve milyonlarca satırı kapsayan devasa değişikliklere kadar uzanan çekme isteklerini yönetirken, inceleme deneyimi olağanüstü hızlı ve duyarlı kalmalıdır. Tüm kullanıcılar için artık varsayılan olan Değişen Dosyalar sekmesi için yeni React tabanlı deneyimin yakın zamanda kullanıma sunulması, özellikle bu zorlu büyük çekme istekleri için sağlam performansın sağlanmasında çok önemli bir yatırım oldu. Bu taahhüt, optimize edilmiş render, etkileşim gecikmesi ve bellek tüketimi gibi zorlu sorunlarla sürekli olarak mücadele etmeyi içeriyordu.

Bu optimizasyonlardan önce, çoğu kullanıcı duyarlı bir deneyim yaşarken, büyük çekme istekleri kaçınılmaz olarak fark edilir performans düşüşlerine yol açıyordu. Aşırı durumlarda JavaScript yığınının 1 GB'ı aştığı, DOM düğüm sayılarının 400.000'i geçtiği ve sayfa etkileşimlerinin aşırı yavaş veya hatta kullanılamaz hale geldiği görüldü. Sonraki Boyaya Etkileşim (INP) gibi temel yanıt verme metrikleri kabul edilebilir seviyelerin üzerine çıkarak kullanıcılar için elle tutulur bir girdi gecikmesi hissi yaratıyordu. Bu makale, GitHub'ın bu temel performans metriklerini önemli ölçüde iyileştirmek ve diff inceleme deneyimini dönüştürmek için üstlendiği ayrıntılı yolculuğu ele alıyor.

Performans Engellerini Aşmak: Çok Stratejili Bir Yaklaşım

Değişen Dosyalar sekmesi için performans incelemesini başlattığında, tek bir "gümüş kurşun" çözümün yeterli olmayacağı kısa sürede anlaşıldı. Her özelliği ve tarayıcıya özgü davranışı korumak için tasarlanmış teknikler, aşırı veri yüklerinde genellikle bir sınıra ulaşıyordu. Tersine, yalnızca en kötü senaryoları önlemeye yönelik hafifletmeler, günlük incelemeler için olumsuz ödünleşimler getirebilirdi.

Bunun yerine, GitHub'ın mühendislik ekibi, her biri belirli çekme isteği boyutlarını ve karmaşıklıklarını ele almak için titizlikle tasarlanmış kapsamlı bir strateji seti geliştirdi. Bu stratejiler üç ana tema üzerine kuruluydu:

Diff-Satır Bileşenleri İçin Odaklanmış Optimizasyonlar: Çekme isteklerinin çoğunluğu için birincil diff deneyiminin verimliliğini artırmak. Bu, yerel sayfada bulma gibi beklenen işlevlerden ödün vermeden orta ve büyük incelemelerin hızlı kalmasını sağladı.
Sanallaştırma ile Zarif Bozunma: Duyarlılık ve kararlılığı ön planda tutarak ve herhangi bir anda render edilen içeriği akıllıca sınırlayarak en büyük çekme istekleri için kullanılabilirliği sağlamak.
Temel Bileşenlere ve Render İyileştirmelerine Yatırım: Kullanıcının özel görüntüleme modundan bağımsız olarak, her çekme isteği boyutunda bileşik faydalar sağlayan iyileştirmeler uygulamak.

Bu stratejik sütunlar, ekibin çabalarına rehberlik ederek performans sorunlarının temel nedenlerini sistematik olarak ele almalarına ve sonraki mimari iyileştirmeler için zemin hazırlamalarına olanak sağladı.

V1'i Ayrıştırmak: Maliyetli Bir Diff Satırının Bedeli

GitHub'ın v1 olarak adlandırılan ilk React tabanlı uygulaması, modern diff görünümünün temelini attı. Bu sürüm, klasik Rails görünümünü React'e taşımak, küçük, yeniden kullanılabilir React bileşenleri oluşturmayı ve net bir DOM ağacı yapısını korumayı önceliklendiren samimi bir çabaydı. Ancak, başlangıçta mantıklı olsa da, bu yaklaşım ölçekte önemli bir darboğaz olduğunu kanıtladı.

v1'de, her diff satırını render etmek maliyetli bir işlemdi. Birleşik bir görünümdeki tek bir satır tipik olarak yaklaşık 10 DOM öğesine dönüşürken, bölünmüş bir görünüm 15'e yakınını gerektiriyordu. Bu sayı, sözdizimi vurgulama ile daha da artar ve çok daha fazla <span> etiketi eklerdi. React katmanında, birleşik diff'ler satır başına en az sekiz bileşen içerirken, bölünmüş görünümler en az 13 bileşen içeriyordu. Bunlar temel sayılardı; yorumlar, üzerine gelme ve odaklanma gibi ekstra UI durumları daha da fazla bileşen ekliyordu.

v1 mimarisi ayrıca React olay işleyicilerinin çoğalmasından da muzdaripti. Küçük ölçekte zararsız görünse de, tek bir diff satırı 20 veya daha fazla olay işleyicisi taşıyabilirdi. Büyük bir çekme isteğinde binlerce satır boyunca çarpıldığında, bu hızla birikerek aşırı ek yüke ve artan JavaScript yığını kullanımına yol açıyordu. Bu karmaşıklık sadece performansı etkilemekle kalmadı, aynı zamanda geliştirmeyi ve bakımı da daha zor hale getirdi. Sınırlı veriler için etkili olan ilk tasarım, GitHub'ın çeşitli çekme isteği boyutlarının sınırsız doğasıyla karşılaştığında önemli ölçüde zorlandı.

Özetlemek gerekirse, her v1 diff satırı için sistem şunlara sahipti:

En az 10-15 DOM ağacı öğesi
En az 8-13 React Bileşeni
En az 20 React Olay İşleyicisi
Çok sayıda küçük, yeniden kullanılabilir React Bileşeni

Bu mimari, daha büyük çekme isteği boyutlarını daha yavaş INP ve artan JavaScript yığını kullanımı ile doğrudan ilişkilendiriyordu, bu da temel bir yeniden değerlendirme ve yeniden tasarım gerektiriyordu.

Render'ı Devrimleştirme: V2 Optimizasyonlarının Etkisi

v2'ye geçiş, ayrıntılı, etkili değişikliklere odaklanan önemli bir mimari revizyonu işaret etti. Ekip, "performans söz konusu olduğunda hiçbir değişikliğin çok küçük olmadığı, özellikle ölçekte" felsefesini benimsedi. Buna önemli bir örnek, satır numarası hücrelerinden gereksiz <code> etiketlerinin kaldırılmasıydı. Her diff satırından iki DOM düğümünü düşürmek önemsiz görünebilir, ancak 10.000 satırda bu, DOM'da anında 20.000 daha az düğüm anlamına geliyordu, bu da hedeflenmiş, artımlı optimizasyonların nasıl önemli iyileşmeler sağladığını gösteriyordu.

Aşağıdaki görsel karşılaştırma, v1'den v2'ye bileşen seviyesindeki azalmış karmaşıklığı vurguluyor:

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.

Düzene Sokulmuş Bileşen Mimarisi

v2'deki temel bir yenilik, bileşen ağacını basitleştirmeyi içeriyordu. Ekip, her diff satırı için sekiz React bileşeninden ikiye düştü. Bu, derinlemesine iç içe geçmiş bileşen ağaçlarını ortadan kaldırarak ve her bölünmüş ve birleşik diff satırı için özel bileşenler oluşturarak başarıldı. Bu, bazı kod tekrarları getirmiş olsa da, veri erişimini önemli ölçüde basitleştirdi ve genel karmaşıklığı azalttı. Olay işleme de merkezileştirildi; artık v1'deki çok sayıda bireysel olay işleyicisinin yerini alarak data-attribute değerleri kullanan tek bir üst düzey işleyici tarafından yönetiliyordu. Bu yaklaşım, hem kodu hem de performansı önemli ölçüde düzene soktu.

Akıllı Durum Yönetimi ve O(1) Veri Erişimi

Belki de en etkili değişiklik, yorum yapma ve bağlam menüleri gibi karmaşık uygulama durumunu koşullu olarak render edilen alt bileşenlere taşımak oldu. GitHub gibi bir ortamda, çekme isteklerinin binlerce satırı aşabildiği durumlarda, yalnızca küçük bir kısmında yorum olacakken her satırın karmaşık yorum durumunu taşıması verimsizdir. Bu durumu iç içe geçmiş bileşenlere taşıyarak, diff-satır bileşeninin birincil sorumluluğu tamamen kod render etmek haline geldi ve Tek Sorumluluk İlkesi ile uyumlu hale geldi.

Ayrıca, v2, v1'i rahatsız eden O(n) aramaları ve aşırı useEffect kancaları sorununu ele aldı. Ekip, iki parçalı bir strateji benimsedi: useEffect kullanımını diff dosyalarının en üst seviyesiyle kesinlikle sınırlamak ve satır sarmalama bileşenlerine yeniden tanıtılmasını önlemek için linting kuralları oluşturmak. Bu, doğru memoizasyon ve öngörülebilir davranış sağladı. Eş zamanlı olarak, genel ve diff durum makineleri, JavaScript Map nesneleri kullanarak O(1) sabit zamanlı aramaları kullanacak şekilde yeniden tasarlandı. Bu, satır seçimi ve yorum yönetimi gibi yaygın işlemler için hızlı, tutarlı seçicilere olanak tanıdı, düzleştirilmiş, eşlenmiş veri yapılarını koruyarak kod kalitesini önemli ölçüde artırdı, performansı iyileştirdi ve karmaşıklığı azalttı. Geliştirici iş akışlarını optimize etme ve temel mimariye yönelik bu titiz yaklaşım, sağlam, ölçeklenebilir bir sistem sağlar.

Ölçülebilir Etki: V2 Niceliksel Kazançlar Sağlıyor

v2'de uygulanan titiz mimari ve kod düzeyindeki optimizasyonlar, temel performans metriklerinde derin, ölçülebilir iyileşmeler sağladı. Yeni sistem, JavaScript yığını kullanımında ve INP puanlarında büyük bir azalmayla önemli ölçüde daha hızlı çalışıyor. Aşağıdaki tablo, bölünmüş bir diff ayarında 10.000 satır değişikliği olan temsili bir çekme isteğinde gözlemlenen çarpıcı iyileşmeleri göstermektedir:

Metrik	v1	v2	İyileşme
JavaScript Yığını	1GB+	250MB	%75
DOM Düğümleri	400,000+	80,000	%80
INP p95	1000ms+	100ms	%90

Bu rakamlar, GitHub'ın çok yönlü stratejisinin başarısını vurgulamaktadır. JavaScript yığın boyutunda %75'lik bir azalma ve DOM düğümlerinde %80'lik bir düşüş, yalnızca daha hafif bir tarayıcı ayak izi anlamına gelmez, aynı zamanda daha kararlı ve duyarlı bir arayüze doğrudan katkıda bulunur. En çarpıcı iyileşme, INP p95'teki (etkileşim gecikmesinin yüzde 95'lik dilimi) %90'lık azalma, kullanıcı etkileşimlerinin %95'inin artık sadece 100 milisaniye içinde tamamlandığı anlamına gelir; bu da v1'deki büyük çekme isteklerini rahatsız eden girdi gecikmesini neredeyse ortadan kaldırır. Bu, kullanıcı deneyimini önemli ölçüde artırarak, büyük kod incelemelerinin küçük olanlar kadar akıcı ve duyarlı hissetmesini sağlar.

Diff-satır optimizasyonuna yönelik bu derinlemesine inceleme ile kanıtlanan GitHub'ın sürekli iyileştirmeye olan bağlılığı, dünya standartlarında bir geliştirici platformu sağlama adanmışlıklarının bir kanıtıdır. Performans darboğazlarını titizlikle analiz ederek ve hedeflenmiş mimari çözümler uygulayarak, yalnızca kritik ölçeklenebilirlik sorunlarını çözmekle kalmamış, aynı zamanda temel ürünlerinde yanıt verme yeteneği için yeni bir standart belirlemişlerdir. Performansa verilen bu odaklanma, mühendislerin kod incelemeleri gibi kritik görevlere verimli bir şekilde katılmalarını sağlar ve sonuçta daha yüksek kod kalitesi ve güvenliği ve daha üretken bir geliştirme ortamı sağlar.

Orijinal kaynak

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

Sık Sorulan Sorular

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.

Güncel Kalın

En son yapay zeka haberlerini e-postanıza alın.

Paylaş