Editor freezes for several seconds when editing or moving around in "large" documents

[goranschwarz]

Description
Editor freezes for several seconds when editing or moving around in large documents

Steps to Reproduce

1. Open a larger file (I normally work with SQL Files, 30-40K lines of SQL)
2. Start to edit the file (I normally do it "near the end of the file)
3. Every now and then the editor "freezes" for a couple of seconds...

Expected behavior
not freezing when editing text

Actual behavior
freezing when editing file

Java version
Compiled on java 8
runtime version: 21.0.1

Additional context
Hi there, it was a long time since my last upgrade of RSyntaxTextArea
I was at: 3.0.2
And went to: 3.5.2

I usually have large files...
And when I'm editing them now, it's good awfull slow at some points
I added a "swing" EventDispatchThreadHangMonitor, which prints a stacktraces if the EDT takes to long...
(possibly from here: https://github.com/floscher/swinghelper/blob/master/src/java/org/jdesktop/swinghelper/debug/EventDispatchThreadHangMonitor.java)

My assumption is that it tries to locate all entries of the "current" string/char, to update the "gutter" of known locations...
and that part of the code is slow (when having a large file)

This is a typical stacktace from EventDispatchThreadHangMonitor

2024-11-11 18:25:21,510 - WARN  - EventDispatchThreadHangMonitor - EventDispatchThreadHangMonitor - Swing EDT-DEBUG - Hang: (hang #407) event dispatch thread stuck processing event for 5269 ms:
    java.desktop/sun.awt.windows.WGlobalCursorManager.setCursor(Native Method)
    java.desktop/sun.awt.GlobalCursorManager._updateCursor(GlobalCursorManager.java:205)
    java.desktop/sun.awt.GlobalCursorManager.updateCursorImmediately(GlobalCursorManager.java:95)
    java.desktop/sun.awt.windows.WComponentPeer.updateCursorImmediately(WComponentPeer.java:710)
    java.desktop/java.awt.Component.updateCursorImmediately(Component.java:3227)
    java.desktop/java.awt.Container.addImpl(Container.java:1174)
    java.desktop/java.awt.Container.add(Container.java:440)
    org.fife.ui.rsyntaxtextarea.ErrorStrip.addMarkersForRanges(ErrorStrip.java:538)
    org.fife.ui.rsyntaxtextarea.ErrorStrip.refreshMarkers(ErrorStrip.java:500)
    org.fife.ui.rsyntaxtextarea.ErrorStrip.access$800(ErrorStrip.java:81)
    org.fife.ui.rsyntaxtextarea.ErrorStrip$Listener.propertyChange(ErrorStrip.java:816)
    java.desktop/java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:343)
    java.desktop/java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:336)
    java.desktop/java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:268)
    java.desktop/java.awt.Component.firePropertyChange(Component.java:8717)
    org.fife.ui.rsyntaxtextarea.RSyntaxTextArea.fireParserNoticesChange(RSyntaxTextArea.java:978)
    org.fife.ui.rsyntaxtextarea.ParserManager.actionPerformed(ParserManager.java:170)
    java.desktop/javax.swing.Timer.fireActionPerformed(Timer.java:311)
    java.desktop/javax.swing.Timer$DoPostEvent.run(Timer.java:243)
    java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
    java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
    java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
    java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
    java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
    java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
    java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
    com.asetune.gui.swing.debug.EventDispatchThreadHangMonitor.dispatchEvent(EventDispatchThreadHangMonitor.java:229)
    java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
    java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
    java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
    java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
    java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
2024-11-11 18:25:21,647 - WARN  - AWT-EventQueue-0               - EventDispatchThreadHangMonitor - Swing EDT-DEBUG - Hang: (hang #407) event dispatch thread unstuck after 5406 ms.

Is this a "known" issue, or has it been introduced somewhere between 3.0.2 -> 3.5.2
Do I need to back to version 3.0.2 (or do you recommend using any other prior version)

Thanks for the good work

[bobbylight]

It's not a solution, but can you see if it still occurs if you call errorStrip.setShowMarkedOccurrences(false)? Might be a workaround while a fix is researched.

[goranschwarz]

You suggestion, does help: (no more long freeze)*, but on the other hand then some functionality get lost

• setMarkOccurrences(false)
• or errorStrip.setShowMarkedOccurrences(false) a better option than setMarkOccurrences(false) less functionality loss

Additional info:

• In my SQL Files, the , character is present in many places
  and it's mainly when I enter a , character it starts to freeze.
  I still want markOccurrences for a single character, since in SQL many people are using a single char as a table alias...
• So a workaround might be to not consider some characters like , to be part of *MarkOccurrences functionality
  or possibly a method setMarkOccurrencesSkipChars(char[] skipChars)
  And in most languages, you probably do not want to mark the occurrences for a , (so it's probably a good character to not mark as the default)

[bobbylight]

Good point. One gross thing is most TokenMakers seem to consider ,, ; and . (or a subtle variatin of that triplet) as "identifiers" primarily to look better while rendering in our default Themes, but that has the side effect of making them trigger the marked occurrences support.

There are a few ways to tackle this, but I'll probably pick a simple route for a 3.5.x release and do something more robust with an API change in the upcoming 4.0.0 major release. Thanks for bringing this up!

[bobbylight]

The chars above should no longer trigger the Mark Occurrences, so hopefully that addresses common cases here.

I suppose this is still possible, but it gets harder to solve in the general case. ErrorStrip uses child components for its marker icons since that's an easy way to get custom mouse cursor support, tool tips, etc., but that's the meat of the slowness. If that could be replaced with custom-rendering based on an in-memory List, I'd imagine it would be much faster, but also much more error-prone. I'll leave this open for a bit though if you have ideas for low-hanging fruit for performance improvements.

[goranschwarz]

Thanks for the quick response!
And I have no low-hanging fruit for performance improvements