Sometimes the Generic Text Editor performs very poorly

[iloveeclipse]

          Sometimes the Generic Text Editor performs so poorly that I close it and use the crappy old editor without the pretty coloring, e.g., this file is difficult to edit at times:

https://github.com/eclipse-orbit/orbit-simrel/blob/main/maven-bnd/tp/MavenBND.target

The poor performance (freezing the UI for ~8 seconds) also happens in the target editor source tab, I expect for the same reason. Only the crappy old editor doesn't need to pay the prettiness penalty for this 3000 line XML file. Of course I really like the prettiness when the cost isn't intolerable...

Originally posted by @merks in #1532 (comment)

[iloveeclipse]

@merks : I can't reproduce the freeze with given file, opening the file with generic text editor plus tm4e installed (to get XML syntax support), not with target editor.

Opening with target editor indeed freezes it, so I assume it's PDE resolver that hangs the UI. Could you confirm that?

[mickaelistria]

Most operations in the generic editor are supposed to be asynchronous, at least it's really what is intended by design. It could be that one of them isn't implemented accordingly and should be fixed.
@merks if you see such freeze, can you please try to capture a jstack and share it here?

[merks]

I'll try to find time to reproduce it. Oddly even with the freeze monitoring enabled, it does not report any problem because that would have helped to see a stack trace to understand where it's freezing. Also the environment where I see it currently isn't completely up-to-date...

[nlisker]

I tried on Eclipse 4.33 and 4.32 with TextMate 0.13 to open the huge file with both the generic editor and the default editor and didn't see a freeze.

[merks]

I created a new environment from scratch with the latest of everything and follow these steps.

• Open ManveBND.target with Generic Text Editor.
• Scroll near the bottom of the file.
• Type space and backspace a few times at the end of a line. If you do it really quickly, you can do it a bunch of time, but if you do it slowly, the freeze kicks in.

I'll try to get a stack trace. Monitoring doesn't help:

[merks]

The main thread is doing this:

"main" #1 [11640] prio=6 os_prio=0 cpu=75796.88ms elapsed=887.29s tid=0x0000021ddb984420 nid=11640 runnable  [0x000000a11cdad000]
   java.lang.Thread.State: RUNNABLE
	at org.eclipse.jface.text.rules.PatternRule.endSequenceDetected(PatternRule.java:243)
	at org.eclipse.jface.text.rules.PatternRule.doEvaluate(PatternRule.java:202)
	at org.eclipse.jface.text.rules.PatternRule.evaluate(PatternRule.java:310)
	at org.eclipse.jface.text.rules.PatternRule.evaluate(PatternRule.java:214)
	at org.eclipse.jface.text.rules.RuleBasedScanner.nextToken(RuleBasedScanner.java:170)
	at org.eclipse.jface.text.rules.DefaultDamagerRepairer.createPresentation(DefaultDamagerRepairer.java:179)
	at org.eclipse.pde.internal.genericeditor.target.extension.reconciler.presentation.TargetPlatformPresentationReconciler.createPresentation(TargetPlatformPresentationReconciler.java:124)
	at org.eclipse.jface.text.presentation.PresentationReconciler.processDamage(PresentationReconciler.java:549)
	at org.eclipse.jface.text.presentation.PresentationReconciler$InternalListener.textChanged(PresentationReconciler.java:215)
	at org.eclipse.jface.text.TextViewer.updateTextListeners(TextViewer.java:2795)
	at org.eclipse.jface.text.TextViewer.invalidateTextPresentation(TextViewer.java:3439)
	at org.eclipse.jface.text.source.projection.ProjectionViewer.executeProjectionCommands(ProjectionViewer.java:1008)
	at org.eclipse.jface.text.source.projection.ProjectionViewer.catchupWithProjectionAnnotationModel(ProjectionViewer.java:983)
	at org.eclipse.jface.text.source.projection.ProjectionViewer.lambda$0(ProjectionViewer.java:891)
	at org.eclipse.jface.text.source.projection.ProjectionViewer$$Lambda/0x0000021d82225420.run(Unknown Source)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132)
	- locked <0x0000000099276748> (a org.eclipse.swt.widgets.RunnableLock)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4099)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3715)

Interesting that PDE's TargetPlatformPresentationReconciler is involved.

Here's the full trace:

generic-editor.txt

[nlisker]

I created a new environment from scratch with the latest of everything and follow these steps.

I tried it and didn't see a freeze, even recorded evidence :)

[merks]

Note that my comment about PDE being involved? The environment is the Orbit one setup like this:

https://github.com/eclipse-orbit/orbit-simrel/blob/main/CONTRIBUTING.md

In any case, I was merely pointing out that having a fall-back editor without all the bells and whistles can on occasion be helpful.

[mickaelistria]

Note that my comment about PDE being involved?

Yes, it looks like PDE reconciler blocks the UI for a long time. The reconcilers cannot really run out of UI thread because some of the data that's necessary for computation is SWT-level and needs UI access, but usually what reconcilers do when they're slow is that instead of computing in the UI Thread, they fetch the necessary data from UI Thread, then trigger computation asynchronously and send there change back to the viewer.
I suspect PDE doesn't do that. It could for sure be improved. TM4E can be a good example.