kunwp1 opened a new issue, #6284:
URL: https://github.com/apache/texera/issues/6284

   ### What happened?
   
   Opening a dataset whose selected version contains ~400 files takes ~7 
seconds before the file tree appears, the tree paints only partially at first, 
and once it shows up the whole frontend UI is unresponsive — clicks and 
scrolling do nothing for tens of seconds. With ~1,100 files the page is frozen 
for minutes. The same freeze hits right after clicking Submit in "Create New 
Version", because the page then loads and renders the new version's file tree — 
the version itself is created successfully on the backend.
   
   **Expected:** the file tree displays quickly and the page stays responsive 
regardless of file count.
   
   **Root cause** (verified with a CPU profile): the version file tree 
(`user-dataset-version-filetree`, `@ali-hm/angular-tree-component`) renders all 
N nodes as full components — virtualization (`useVirtualScroll`) is not 
enabled. Each row contains an `nz-button` whose `afterEveryRender` hook reads 
layout after every change-detection pass, so every pass performs N forced 
reflows over an N-row DOM — O(N²) main-thread work. Memory is not the problem: 
heap stays at ~100–134 MB with no crash; the renderer main thread is simply 
starved.
   
   ```
   Before:  open dataset (or Submit new version) -> render all N tree nodes -> 
each CD pass: N layout reads over N-row DOM -> main thread frozen, O(N^2)
   After:   open dataset -> virtualized tree renders only visible rows -> CD 
pass is O(visible rows) -> page stays responsive
   ```
   
   Measured on main with `ng serve`, Chrome (headless, Long Tasks API), 
datasets with N one-byte files:
   
   | N files | Wall time until page usable | Total main-thread blocked | 
Longest single block |
   |---|---|---|---|
   | 100 | 3.6 s | 1.3 s | 0.7 s |
   | 200 | 6.4 s | 4.3 s | 2.5 s |
   | 400 | 24.5 s | 22.2 s | 13.8 s |
   | 800 | 103.8 s | 101.5 s | 63.7 s |
   
   Each doubling of N costs ~4× more blocked time. Related to #5586 (same 
unbounded-rendering pattern in the upload lists; this issue is the version file 
tree).
   
   **Proposed fix:** virtualize the file tree so only visible rows are in the 
DOM — either `angular-tree-component`'s `useVirtualScroll` option with a 
fixed-height container, or the `cdk-virtual-scroll` approach used for the 
Pending/Finished lists in #5586.
   
   ### How to reproduce?
   
   1. Create a dataset and upload ~400 small files (e.g. 1 byte each), then 
click Submit to create a version — or open any existing dataset whose latest 
version has ≥400 files.
   2. Open the dataset detail page (the version file tree loads automatically).
   3. Observe: several seconds before the tree appears, partial rendering, and 
an unresponsive page afterwards (Chrome may show "Page Unresponsive"); duration 
grows quadratically with file count.
   
   ### Version/Branch
   
   1.3.0-incubating-SNAPSHOT (main)
   
   ### What browsers are you seeing the problem on?
   
   Chrome (the root cause is browser-agnostic, so other browsers are likely 
affected as well)
   
   ### Relevant log output
   
   ```
   No JavaScript errors in the console. The renderer main thread is blocked
   (Long Tasks API: single tasks up to ~64 s at N=800; heap steady at ~100-134 
MB, no OOM).
   ```
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to