PDE Reconciler slow and blocking the UI

[vogella]

See eclipse-platform/eclipse.platform.ui#2276

[vogella]

Root cause

TargetPlatformPresentationReconciler overrides createPresentation() and always scans from offset 0 to document.getLength() on every keystroke. The comment in the code explains why: the <!-- ... --> multi-line comment rule requires scanning from the beginning of the document so the scanner has full context when it reaches the damaged region. Without this, a comment that started before the damage would be missed.

The problem is that this full-document scan happens synchronously on the UI thread. For a 3000-line file, that means scanning ~150 000 characters, calling PatternRule.endSequenceDetected() for each one, every time the user types a character.

The relevant lines are in TargetPlatformPresentationReconciler.createPresentation():

ITypedRegion[] regions = TextUtilities.computePartitioning(document, getDocumentPartitioning(), 0,
        document.getLength(), false);  // ← always scans full document
if (regions.length > 0) {
    repairer.createPresentation(presentation, regions[0]);

There is also a secondary issue: the code computes all partitions but then only uses regions[0], discarding the rest. For the .target format this happens to be harmless (there is only one content type), but it is confusing.

Proposed fix (Option 1 — limit scan to damage end)

Replace document.getLength() with damage.getOffset() + damage.getLength(). This limits the scan to the portion of the document up to and including the damaged region.

Why this is safe: the TextPresentation returned by createPresentation is already bounded by the damage region (it is constructed as new TextPresentation(damage, 1000)), so any style ranges added for content after the damage end are silently discarded anyway. Scanning from 0 is preserved, so the scanner still has full context for multi-line rules that opened before the damage.

Limitation: for edits near the very end of a large file, the damage end ≈ document end, so the gain is small. The real long-term fix would be to move the reconciliation work off the UI thread entirely (similar to how TM4E handles it), but that is a larger refactor. This change is a safe, minimal improvement that avoids the clearly wasted work of scanning content the presentation will never use.

[vogella]

Option 2 — fix the unused-regions bug

The current createPresentation override has a secondary bug: it calls TextUtilities.computePartitioning() over the whole document, which may return multiple ITypedRegion entries, but then unconditionally passes only regions[0] to the repairer, discarding everything else.

For the .target format this is harmless today because there is only one content type (DEFAULT_CONTENT_TYPE) and computePartitioning therefore returns exactly one region. But it is fragile and misleading.

The fix is to find the region that actually covers the damage start and pass that one (or iterate over all regions that overlap the damage):

for (ITypedRegion region : regions) {
    IPresentationRepairer repairer = getRepairer(region.getType());
    if (repairer != null) {
        repairer.createPresentation(presentation, region);
    }
}

Combined with Option 1 (limit scan to damage end) this is a clean, correct replacement for the whole override.

Option 3 — move reconciliation off the UI thread (proper long-term fix)

Both Option 1 and Option 2 still do O(damage end) work synchronously on the UI thread. For documents where the damage is always near the end (the reported scenario: editing at line 3000 of 3000), they provide little relief.

The root fix is to perform the scanning on a background thread and apply the resulting TextPresentation back on the UI thread via asyncExec, similar to how TM4E's TMPresentationReconciler works:

1. On the UI thread (cheap): snapshot the current document content and damage region.
2. On a background Job: run computePartitioning and the scanner over the snapshot.
3. Back on the UI thread via Display.asyncExec: apply the finished TextPresentation to the viewer.

Any new edit that arrives while the background job is still running cancels it and starts a fresh one, keeping the UI responsive.

This is a larger refactor — PresentationReconciler would need to be replaced or extended significantly — but it is the only approach that eliminates UI-thread blocking for large files regardless of where in the document the edit occurs.