Text search freezes UI

[iloveeclipse]

Follow up on https://github.com/eclipse-platform/eclipse.platform.ui/issues/872

This seem to be a regression after 4.25.

I can't reproduce on 4.25 but I can reproduce on master / SDK-I20230426-1800-linux-gtk-x86_64.

In my workspace that contains most of SDK bundles as sources case-insensitive searching for "a" in all files freezes UI after roughly 1.000.000 matches and at 2%, staying in that state with 100% CPU load for minutes. I have to kill IDE because it become not responsible.

In my (other and bigger) workspace on 4.25 search takes few seconds to find 26.000.000 matches without any freeze.

In the jstacks I see AbstractTextSearchResult.getMatchCount() that is almost always on top

"main" eclipse-platform/eclipse.platform.text#1 prio=6 os_prio=0 cpu=538026.91ms elapsed=20829.88s tid=0x00007ffff0028f70 nid=0x9676 runnable  [0x00007ffff7fb6000]
   java.lang.Thread.State: RUNNABLE
    at java.util.concurrent.ConcurrentHashMap$Traverser.advance(java.base@17.0.6-internal/ConcurrentHashMap.java:3383)
    at java.util.concurrent.ConcurrentHashMap$ValueIterator.next(java.base@17.0.6-internal/ConcurrentHashMap.java:3483)
    at org.eclipse.search.ui.text.AbstractTextSearchResult.getMatchCount(AbstractTextSearchResult.java:305)
    at org.eclipse.search.internal.ui.text.FileTreeContentProvider.getMatchCount(FileTreeContentProvider.java:189)
    at org.eclipse.search.internal.ui.text.FileTreeContentProvider.elementsChanged(FileTreeContentProvider.java:239)
    - locked <0x0000000456e67178> (a org.eclipse.search.internal.ui.text.FileTreeContentProvider)
    at org.eclipse.search.internal.ui.text.FileSearchPage.elementsChanged(FileSearchPage.java:343)
    at org.eclipse.search.ui.text.AbstractTextSearchViewPage.runBatchedUpdates(AbstractTextSearchViewPage.java:1263)
    at org.eclipse.search.ui.text.AbstractTextSearchViewPage$UpdateUIJob.runInUIThread(AbstractTextSearchViewPage.java:154)
    at org.eclipse.ui.progress.UIJob.lambda$0(UIJob.java:148)
    at org.eclipse.ui.progress.UIJob$$Lambda$725/0x00000008012bee70.run(Unknown Source)
    at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
    at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132)
    - locked <0x0000000454260438> (a org.eclipse.swt.widgets.RunnableLock)
    at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:5040)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4520)

[iloveeclipse]

@jjohnstn, @mickaelistria : seem to be regression from eclipse-platform/eclipse.platform.text#144. Could you please check?

[iloveeclipse]

I assume (after briefly looking into the change eclipse-platform/eclipse.platform.text#144) that this line in the for loop adds extra N^2 or higher complexity counting how many matches found for each found search match: https://github.com/eclipse-platform/eclipse.platform.text/blob/549c9584b0fff4fd102729a12de2d6e425cf88de/org.eclipse.search/search/org/eclipse/search/internal/ui/text/FileTreeContentProvider.java#L239

[merks]

Note too that I've occasionally seen a search view that shows fewer matches than the count says should be present, but if I repeat the search, then it all looks correct with all the matches present. This is very disconcerting, but not reproducible...

[jjohnstn]

@iloveeclipse Will look at it.

[iloveeclipse]

@jjohnstn : I was unfortunately in the meeting, so couldn't test, but check this idea: https://github.com/eclipse-platform/eclipse.platform.text/pull/188 - if the problem is like in the line above.

[iloveeclipse]

Actually it looks like eclipse-platform/eclipse.platform.text#188 fixes the issue. I can search and find 19.000.000 matches in few seconds in the workspace where it was frozen before.

[jjohnstn]

@iloveeclipse Please see my comment on eclipse-platform/eclipse.platform.text#188