Summary
Opening the compare editor for relatively simple text sources that contain repeated ins(...) statements (with long comma‑separated argument lists) becomes excessively slow and sometimes unresponsive. The issue is observed when calling CompareUI.openCompareEditor(input) with ~2,600 lines on each side. The slowdown appears proportional to line count and argument length, not just file size, suggesting a pathological case in tokenization or diff calculation.
Steps to Reproduce
-
Prepare two files of similar size (~2,600 lines each) comprised of repeated statements like below.
-
Ensure default Compare preferences (no special ignore rules).
-
Via API: Build a CompareEditorInput (e.g., Differencer/CompareConfiguration) and call CompareUI.openCompareEditor(input);
-
Measure time from invocation to the compare editor becoming responsive.
Example Source Content
Old (old.txt)
ins(app_install#.inst_in_list('LI,CH,AT,SG,HK'),'aaa','6000',0,null,null,'[0:[','GROSS','aaa','GROSS','*1');
New (new.txt)
ins(app$install#.inst_in_list('LI,CH,AT,SG,HK'),'aaa','6000',0,null,null,'[0:[','GROSS','aaa','GROSS','*1',null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null);
It seems that the Eclipse Compare editor (via CompareUI.openCompareEditor) hangs because it uses an LCS-based (Longest Common Subsequence) diff that performs extremely poorly on very long single-line statements with shifted parameters. The new source version (new.txt) turns one line into a worst-case diff scenario, causing the UI thread to block indefinitely.