Opening a compare editor (for example from the Git History or Git Staging view) takes long, even for small files. The same applies to the new unified diff display.
Tracing the open path in org.eclipse.compare shows the delay is structural, not in the diff algorithm (see also #2575, where a DocLineComparator micro-optimization did not help):
- The input contents are read repeatedly during a single open. A new counting test measures 15
getContents() calls per side for one editor open. With EGit inputs each call re-inflates the blob since StorageTypedElement only buffers the storage handle.
- After the "Comparing..." job, everything else runs on the UI thread inside
createContents. Timing tests confirm time-to-text equals time-to-diff, so nothing is visible until the diff completes (about 190 ms for 5000 lines with 100 changes, about 310 ms for 50000 lines, measured on Linux/Xvfb).
- With the unified diff preference enabled,
CompareUIPlugin.canShowInUnifiedDiff runs the full prepareInput synchronously on the UI thread with a NullProgressMonitor, builds a throwaway TextMergeViewer on an invisible Shell, and UnifiedDiffManager.open then computes a second diff inline on the UI thread.
I plan to address this incrementally: measurable tests first (deterministic call counters plus repeated-run timing medians, since the old org.eclipse.test.performance-based tests assert nothing without the performance database), then removing the redundant lookups and reads, then moving the unified path onto the same background-job pattern as the classic editor, and finally making the initial diff asynchronous so the text shows immediately.
See also #121 for a related problem after the compare editor opens.
Opening a compare editor (for example from the Git History or Git Staging view) takes long, even for small files. The same applies to the new unified diff display.
Tracing the open path in org.eclipse.compare shows the delay is structural, not in the diff algorithm (see also #2575, where a DocLineComparator micro-optimization did not help):
getContents()calls per side for one editor open. With EGit inputs each call re-inflates the blob sinceStorageTypedElementonly buffers the storage handle.createContents. Timing tests confirm time-to-text equals time-to-diff, so nothing is visible until the diff completes (about 190 ms for 5000 lines with 100 changes, about 310 ms for 50000 lines, measured on Linux/Xvfb).CompareUIPlugin.canShowInUnifiedDiffruns the fullprepareInputsynchronously on the UI thread with aNullProgressMonitor, builds a throwawayTextMergeVieweron an invisibleShell, andUnifiedDiffManager.openthen computes a second diff inline on the UI thread.I plan to address this incrementally: measurable tests first (deterministic call counters plus repeated-run timing medians, since the old
org.eclipse.test.performance-based tests assert nothing without the performance database), then removing the redundant lookups and reads, then moving the unified path onto the same background-job pattern as the classic editor, and finally making the initial diff asynchronous so the text shows immediately.See also #121 for a related problem after the compare editor opens.