[go: up one dir, main page]

Investigate performance impact of removing RecycleScroller from file tree browser

Context

RecycleScroller was removed from the file tree browser in !207844 (merged) to implement proper ARIA tree view patterns for accessibility. The RecycleScroller's DOM recycling broke keyboard navigation and made it difficult to maintain proper ARIA element relationships.

However, RecycleScroller was originally added because Vue 2 components are expensive to create. With large file trees, this can cause noticeable performance issues.

Performance observations

Testing on the Source Code Management Test Project:

  • ✅ Loading 1500 files and general interaction remained stable
  • ✅ Initial page load with ~500 files showed acceptable performance
  • ⚠️ Collapsing the mock_files folder caused 1-6 seconds of main thread blocking

This is a tradeoff between accessibility and performance that needs investigation.

Goal

Understand the real-world performance impact and decide if the tradeoffs are acceptable.

Testing needed

1. Performance benchmarks

Test with different file tree sizes (20, 200, 500, 1000, 1500+ files):

  • Initial render time
  • Expand/collapse folder time
  • Main thread blocking time
  • Memory usage

2. Repository analysis

  • What's the typical number of files in GitLab repositories?
  • What percentage of repos have >500 files? >1000 files?

3. Decision

Based on the data, decide:

  • Keep current implementation (no RecycleScroller) - acceptable performance
  • Revert to RecycleScroller - performance issues too significant
  • Hybrid approach - use RecycleScroller only for trees above a threshold (e.g., 500 files)

Related

Edited by 🤖 GitLab Bot 🤖