Search View: Performance issues on remove and sort by mehmet-karaman · Pull Request #3733 · eclipse-platform/eclipse.platform.ui

mehmet-karaman · 2026-02-17T14:17:58Z

Implemented a batch removal of search matches
Search matches are removed from their parent, instead of one by one
which causes performance issues
It's also fixing the problem, that all elements are removed instead
only the visible elements (while all others are filtered by the limit
number)
Replaces the
ConcurrentHashMap.newKeySet() with the ConcurrentSkipListSet with the
comparator and makes the additional sorting obsolete.

iloveeclipse · 2026-02-17T14:21:47Z

@mehmet-karaman : please first create a ticket and explain the problem.
Note: you seem to use wrong git author mail, please use same which you've used in ECA process.

github-actions · 2026-02-17T15:34:19Z

Test Results

3 024 files ±0 3 024 suites ±0 2h 11m 12s ⏱️ - 5m 32s
8 234 tests ±0 7 986 ✅ ±0 248 💤 ±0 0 ❌ ±0
23 526 runs ±0 22 735 ✅ ±0 791 💤 ±0 0 ❌ ±0

Results for commit 7d37158. ± Comparison against base commit 89a19bf.

♻️ This comment has been updated with latest results.

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchResult.java

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchViewPage.java

iloveeclipse · 2026-02-18T15:38:22Z

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchViewPage.java

+		if (!parents.isEmpty()) {
+			result.removeParents(parents);
+			if (others.isEmpty()) {
+				return;


This doesn't update UI, at least not for me.
I see the tree in the search view, select subtree, click on delete ... nothing happens at all now.
What is missing is the code that updates UI after this operation.

I'm using exact this steps: #3735 (comment), should be reproducible for everyone.

I hope i understood it correct, I have tried to record what is currently on my branch:

Videoprojekt.4.mp4

As explained in the reproduction scenario.. Could it be that you didn't checked out that commit?

Please just follow steps I've provided.

Now I got it.. It seems that the method AbstractTextSearchResult.removeElements(List<?>) gets called with wrong 'enclosing' elements.. My solution needs to take care on deeper folder structures and gather all IFiles..

I've added a resource visitor which collects all IFiles inside of the selected 'enclosing' element.. Could be a better way to achieve this.. Maybe I should use the ContentProvider and navigate through the search results instead?

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchResult.java

Copilot

Pull request overview

This PR addresses Search View performance and correctness when removing matches, by enabling batch removal at the “enclosing element” (e.g., file/resource) level and ensuring removals aren’t limited to only currently visible (element-limited) results.

Changes:

Updated AbstractTextSearchViewPage.internalRemoveSelected() to batch-remove matches by selected IFile / IContainer resources before falling back to per-match removal for non-resource selections.
Added AbstractTextSearchResult.removeElements(...) to remove all matches for selected elements via a single map-entry removal per element.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
`bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchViewPage.java`	Adds resource-aware pre-processing in “Remove Selected Matches” to remove matches by file/container in a batch.
`bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchResult.java`	Introduces an element-based batch removal method to efficiently drop all matches for selected elements.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchViewPage.java

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchResult.java

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchViewPage.java

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchResult.java

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-02-19T14:18:02Z

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchResult.java

 	}

+	/**
+	 * @return {@code true} if the result is not empty


The Javadoc description is incorrect or incomplete. It says "if the result is not empty" but should describe that this method checks if the specified element has any matches, not whether the entire result is not empty. Consider updating the documentation to something like "Returns true if the given element has matches" to clarify the method's purpose.

Suggested change

* @return {@code true} if the result is not empty

* Returns {@code true} if the given element has matches.

Copilot · 2026-02-19T14:18:03Z

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchResult.java

+	 *
+	 * @param elements
+	 *            the elements of which matches should be removed.
+	 */
+	void removeElements(List<?> elements) {


The removeElements method is package-private but appears to be a new API method that follows the pattern of other removal methods in this class (removeMatch, removeMatches, removeAll). All other removal methods in AbstractTextSearchResult are public. Consider making this method public for API consistency, and adding proper Javadoc documentation with @SInCE 3.18 tag and "Subclasses may extend this method" as seen in other removal methods. Alternatively, if this is intentionally internal-only, consider adding a comment explaining why it deviates from the pattern.

Suggested change

*

* @param elements

* the elements of which matches should be removed.

*/

void removeElements(List<?> elements) {

* <p>

* Subclasses may extend this method.

* </p>

*

* @param elements

* the elements of which matches should be removed.

*

* @since 3.18

*/

public void removeElements(List<?> elements) {

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchResult.java

Copilot · 2026-02-19T14:18:04Z

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchViewPage.java

+		List<IResource> elementsToRemove = new ArrayList<>();
+		List<Object> others = new ArrayList<>();
+		Object[] resultElements = result.getElements();
+		for (Object selectedObj : selection) {
+			if (selectedObj instanceof IContainer container) {
+				for (Object resElement : resultElements) {
+					if (resElement instanceof IResource res && container.getFullPath().isPrefixOf(res.getFullPath())
+							&& res.getType() == IResource.FILE) {
+						elementsToRemove.add(res);
+					}
+				}
+			} else if (selectedObj instanceof IFile file) {
+				elementsToRemove.add(file);


The elementsToRemove list can contain duplicate IResource entries if a user selects both a container and a file within that container. When processing the container at line 1398-1404, all files under it are added; then if one of those files is also explicitly selected, it gets added again at line 1406. While removeElements handles this gracefully (the second removal is a no-op), this creates unnecessary work. Consider using a Set instead of a List for elementsToRemove, or checking if the file is already in the list before adding it at line 1406.

This can happen. fElementsToMatches is removing the key and if its called second time it returns null which is also catched. So this is also obsolete.

Can be checked here: org.eclipse.search.ui.text.AbstractTextSearchResult.removeElements(List<?>)

- Implemented a batch removal of search matches - Search matches are removed from their parent, instead of one by one which causes performance issues - It's also fixing the problem, that all elements are removed instead only the visible elements (while all others are filtered by the limit number) - Replaces the ConcurrentHashMap.newKeySet() with the ConcurrentSkipListSet with the comparator and makes the additional sorting obsolete. - After this change, avoid using `size()` on values, because it is not more constant time operation, see `ConcurrentSkipListSet` javadoc. - Also comparator must be changed to consider different Match elements with same size and offsets in the set - otherwise the `ConcurrentSkipListSet` would lost them. - Added `AbstractTextSearchResult.hasMatches(Object element)` API for cases where match count not needed. - If possible, calls to `size()` changed to `isEmpty()` or omitted. Fixes eclipse-platform#3735 Co-authored-by: Andrey Loskutov <loskutov@gmx.de>

mehmet-karaman force-pushed the batch_remove_search_matches branch from 2a62c61 to 73cab0d Compare February 17, 2026 14:52

mehmet-karaman force-pushed the batch_remove_search_matches branch 4 times, most recently from dff7693 to 300ca6b Compare February 17, 2026 23:07

iloveeclipse requested changes Feb 18, 2026

View reviewed changes

mehmet-karaman force-pushed the batch_remove_search_matches branch from 300ca6b to fe5e861 Compare February 18, 2026 22:21

mehmet-karaman commented Feb 18, 2026

View reviewed changes

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchResult.java Outdated Show resolved Hide resolved

mehmet-karaman force-pushed the batch_remove_search_matches branch from fe5e861 to 7f02394 Compare February 18, 2026 23:19

iloveeclipse requested a review from Copilot February 19, 2026 08:03

Copilot started reviewing on behalf of iloveeclipse February 19, 2026 08:04 View session

Copilot AI reviewed Feb 19, 2026

View reviewed changes

fedejeanne mentioned this pull request Feb 19, 2026

Search view with millions of matches is freezing the UI #3735

Open

mehmet-karaman force-pushed the batch_remove_search_matches branch 2 times, most recently from 4cd364f to b53503b Compare February 19, 2026 11:20

mehmet-karaman changed the title ~~Search View: Batch removing of search matches~~ Search View: Performance issues on remove and sort Feb 19, 2026

iloveeclipse requested a review from Copilot February 19, 2026 11:56

Copilot started reviewing on behalf of iloveeclipse February 19, 2026 11:56 View session

Copilot AI reviewed Feb 19, 2026

View reviewed changes

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchViewPage.java Show resolved Hide resolved

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchResult.java Outdated Show resolved Hide resolved

mehmet-karaman force-pushed the batch_remove_search_matches branch 2 times, most recently from 17ec4af to fc2f401 Compare February 19, 2026 12:46

iloveeclipse reviewed Feb 19, 2026

View reviewed changes

bundles/org.eclipse.search/newsearch/org/eclipse/search/ui/text/AbstractTextSearchResult.java Outdated Show resolved Hide resolved

iloveeclipse force-pushed the batch_remove_search_matches branch from fc2f401 to 40ee202 Compare February 19, 2026 13:48

iloveeclipse requested a review from Copilot February 19, 2026 14:12

Copilot started reviewing on behalf of iloveeclipse February 19, 2026 14:12 View session

Copilot AI reviewed Feb 19, 2026

View reviewed changes

iloveeclipse force-pushed the batch_remove_search_matches branch from 40ee202 to 7d37158 Compare February 19, 2026 15:13

	* @return {@code true} if the result is not empty
	* Returns {@code true} if the given element has matches.

Conversation

mehmet-karaman commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iloveeclipse commented Feb 17, 2026

Uh oh!

github-actions bot commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

Uh oh!

Uh oh!

Uh oh!

iloveeclipse Feb 18, 2026

Choose a reason for hiding this comment

Uh oh!

iloveeclipse Feb 18, 2026

Choose a reason for hiding this comment

Uh oh!

mehmet-karaman Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iloveeclipse Feb 18, 2026

Choose a reason for hiding this comment

Uh oh!

mehmet-karaman Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mehmet-karaman Feb 18, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

mehmet-karaman Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Comments

mehmet-karaman commented Feb 17, 2026 •

edited

Loading

github-actions bot commented Feb 17, 2026 •

edited

Loading

mehmet-karaman Feb 18, 2026 •

edited

Loading

mehmet-karaman Feb 18, 2026 •

edited

Loading

mehmet-karaman Feb 19, 2026 •

edited

Loading