Closed iloveeclipse closed 1 year ago
@jjohnstn, @mickaelistria : seem to be regression from eclipse-platform/eclipse.platform.text#144. Could you please check?
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
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...
@iloveeclipse Will look at it.
@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.
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.
@iloveeclipse Please see my comment on eclipse-platform/eclipse.platform.text#188
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