Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI freeze when searching over large files. Search View Filter viewer limit is not applied for children in TreeViewer. #2279

Closed
raghucssit opened this issue Sep 16, 2024 · 7 comments
Assignees
Labels
bug Something isn't working performance
Milestone

Comments

@raghucssit
Copy link
Contributor

This issue is already reported here. Please close this one on Bugzilla as duplicate.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=575271

UI freezes over around 12 seconds if have a large search result in the second level tree onwards. The reason is Search View Filter viewer limit is not applied for children.
Use below snippet to generate 100k files with searchable text in it. Initiate File Search with text text here

    public static void main(String[] args) throws IOException {
              Path folder = Paths.get("...");
              if (!Files.deleteIfExists(folder)) {
              	Files.createDirectory(folder);
              }
              int n = 100_000;
              String baseContent = "text here";
              for (int i = 0; i < n; ++i) {
                      System.out.println("Writing file " + i);
                      StringBuilder content = new StringBuilder();
                      int k = 1;
                      if (i == 1001) {
                      	k = 1000;
                      }
                      for (int j = 0; j < k; ++j) {
                      	content.append(baseContent);
                      	content.append(" n");
                      	content.append(i);
                      	content.append(System.lineSeparator());
                      }
                      String fileName = "file" + i + ".txt";
                      Path file = folder.resolve(fileName);
                      try {
                              Files.write(file, content.toString().getBytes());
                      } catch (IOException e) {
                              System.err.println("Failed to write file: " + fileName);
                              e.printStackTrace();
                      }
              }
      }
@raghucssit raghucssit added the bug Something isn't working label Sep 16, 2024
raghucssit added a commit to raghucssit/eclipse.platform.ui that referenced this issue Sep 16, 2024
Currently viewer limit is applied to top level elements. Object[]
getChildren(Object parentElement) missing limit application.

see eclipse-platform#2279
@jukzi
Copy link
Contributor

jukzi commented Sep 16, 2024

Can you please provide screenshot how you search and what the result looks like? Is this a linux issue only?

@raghucssit
Copy link
Contributor Author

This is on linux. I did not test on windows.
UI will not show not responding but nothing can be performed on UI for 12 seconds and more.

100k files in PE. PE don't freeze because there is global viewer limit.
100k-pe

Search results view tries to expand the dir node to select first match.
100k-sv

raghucssit added a commit to raghucssit/eclipse.platform.ui that referenced this issue Sep 17, 2024
Currently viewer limit is applied to top level elements. Object[]
getChildren(Object parentElement) missing limit application.

see eclipse-platform#2279
raghucssit added a commit to raghucssit/eclipse.platform.ui that referenced this issue Sep 17, 2024
Currently viewer limit is applied to top level elements. Object[]
getChildren(Object parentElement) missing limit application.

see eclipse-platform#2279
iloveeclipse added a commit to iloveeclipse/eclipse.platform.ui that referenced this issue Sep 17, 2024
If the search view shows ~100000 matches, deleting resources that are
shown in the search view freezes Eclipse for many minutes. With this
change the freeze is only about 30 seconds.

See eclipse-platform#2279
iloveeclipse pushed a commit that referenced this issue Sep 23, 2024
Currently viewer limit is applied to top level elements. Object[]
getChildren(Object parentElement) missing limit application.

see #2279
iloveeclipse added a commit to iloveeclipse/eclipse.platform.ui that referenced this issue Sep 23, 2024
If the search view shows ~100000 matches, deleting resources that are
shown in the search view freezes Eclipse for many minutes. With this
change the freeze is only about 30 seconds.

See eclipse-platform#2279
iloveeclipse added a commit to iloveeclipse/eclipse.platform.ui that referenced this issue Sep 23, 2024
@iloveeclipse iloveeclipse added this to the 4.34 M1 milestone Sep 23, 2024
iloveeclipse added a commit that referenced this issue Sep 23, 2024
If the search view shows ~100000 matches, deleting resources that are
shown in the search view freezes Eclipse for many minutes. With this
change the freeze is only about 30 seconds.

See #2279
iloveeclipse added a commit that referenced this issue Sep 23, 2024
@iloveeclipse
Copy link
Member

After playing a bit more with search view after merged changes I saw two things:

  1. We still have a full hang (forever on the example with 100.000 files here) after doing "F5" (run the current search again) - this is because the view update code calls AbstractTextSearchResult.getMatchCount() on every element to update and that traverses every match...
  2. The tree mode in the search view doesn't show that the matches were filtered from the view, but table mode does it. This is more relevant now, because we filter more aggressive (not only the first level) and user might wonder "where are all the 1.000.000 matches gone".

I will push a PR addressing both issues in a moment.

iloveeclipse added a commit to iloveeclipse/eclipse.platform.ui that referenced this issue Sep 24, 2024
This change unifies "filter" label handling for tree/table mode in the
file search, we show now that the matches are filtered in both cases.

See eclipse-platform#2279
iloveeclipse added a commit to iloveeclipse/eclipse.platform.ui that referenced this issue Sep 24, 2024
If the search view has matches for 100.000 files, it would hang forever
on updating the view via F5 because it asks getMatchCount() for every
element and that traverses entire result again and again.

This change remembers last computed result and returns that value if
there were no further changes on the search result itself.

See eclipse-platform#2279
@iloveeclipse
Copy link
Member

See #2320

@BeckerWdf
Copy link
Contributor

Once we have fixe this. Is this something we should also put into the New & Noteworthy document?
It's not a new feature but improving performance / reducing UI freezes is always "noteworthy" from my point of view. ;-)

@jukzi
Copy link
Contributor

jukzi commented Sep 24, 2024

we had performance improvements in every version. But at the same time we have so many regressions that it feels odd to praise xyz got faster while people complain uvw became worse.

iloveeclipse added a commit to iloveeclipse/eclipse.platform.ui that referenced this issue Sep 24, 2024
This change unifies "filter" label handling for tree/table mode in the
file search, we show now that the matches are filtered in both cases.

See eclipse-platform#2279
iloveeclipse added a commit to iloveeclipse/eclipse.platform.ui that referenced this issue Sep 24, 2024
If the search view has matches for 100.000 files, it would hang forever
on updating the view via F5 because it asks getMatchCount() for every
element and that traverses entire result again and again.

This change remembers last computed result and returns that value if
there were no further changes on the search result itself.

See eclipse-platform#2279
iloveeclipse added a commit that referenced this issue Sep 24, 2024
This change unifies "filter" label handling for tree/table mode in the
file search, we show now that the matches are filtered in both cases.

See #2279
iloveeclipse added a commit that referenced this issue Sep 24, 2024
If the search view has matches for 100.000 files, it would hang forever
on updating the view via F5 because it asks getMatchCount() for every
element and that traverses entire result again and again.

This change remembers last computed result and returns that value if
there were no further changes on the search result itself.

See #2279
@iloveeclipse
Copy link
Member

All planned fixes merged, closing.

praveen-skp pushed a commit to praveen-skp/eclipse.platform.ui that referenced this issue Oct 14, 2024
Currently viewer limit is applied to top level elements. Object[]
getChildren(Object parentElement) missing limit application.

see eclipse-platform#2279
praveen-skp pushed a commit to praveen-skp/eclipse.platform.ui that referenced this issue Oct 14, 2024
If the search view shows ~100000 matches, deleting resources that are
shown in the search view freezes Eclipse for many minutes. With this
change the freeze is only about 30 seconds.

See eclipse-platform#2279
praveen-skp pushed a commit to praveen-skp/eclipse.platform.ui that referenced this issue Oct 14, 2024
praveen-skp pushed a commit to praveen-skp/eclipse.platform.ui that referenced this issue Oct 14, 2024
This change unifies "filter" label handling for tree/table mode in the
file search, we show now that the matches are filtered in both cases.

See eclipse-platform#2279
praveen-skp pushed a commit to praveen-skp/eclipse.platform.ui that referenced this issue Oct 14, 2024
If the search view has matches for 100.000 files, it would hang forever
on updating the view via F5 because it asks getMatchCount() for every
element and that traverses entire result again and again.

This change remembers last computed result and returns that value if
there were no further changes on the search result itself.

See eclipse-platform#2279
lathapatil pushed a commit to lathapatil/eclipse.platform.ui that referenced this issue Oct 21, 2024
Currently viewer limit is applied to top level elements. Object[]
getChildren(Object parentElement) missing limit application.

see eclipse-platform#2279
lathapatil pushed a commit to lathapatil/eclipse.platform.ui that referenced this issue Oct 21, 2024
If the search view shows ~100000 matches, deleting resources that are
shown in the search view freezes Eclipse for many minutes. With this
change the freeze is only about 30 seconds.

See eclipse-platform#2279
lathapatil pushed a commit to lathapatil/eclipse.platform.ui that referenced this issue Oct 21, 2024
lathapatil pushed a commit to lathapatil/eclipse.platform.ui that referenced this issue Oct 21, 2024
This change unifies "filter" label handling for tree/table mode in the
file search, we show now that the matches are filtered in both cases.

See eclipse-platform#2279
lathapatil pushed a commit to lathapatil/eclipse.platform.ui that referenced this issue Oct 21, 2024
If the search view has matches for 100.000 files, it would hang forever
on updating the view via F5 because it asks getMatchCount() for every
element and that traverses entire result again and again.

This change remembers last computed result and returns that value if
there were no further changes on the search result itself.

See eclipse-platform#2279
elsazac pushed a commit to elsazac/eclipse.platform.ui that referenced this issue Nov 7, 2024
If the search view shows ~100000 matches, deleting resources that are
shown in the search view freezes Eclipse for many minutes. With this
change the freeze is only about 30 seconds.

See eclipse-platform#2279
elsazac pushed a commit to elsazac/eclipse.platform.ui that referenced this issue Nov 7, 2024
This change unifies "filter" label handling for tree/table mode in the
file search, we show now that the matches are filtered in both cases.

See eclipse-platform#2279
elsazac pushed a commit to elsazac/eclipse.platform.ui that referenced this issue Nov 7, 2024
elsazac pushed a commit to elsazac/eclipse.platform.ui that referenced this issue Nov 8, 2024
If the search view shows ~100000 matches, deleting resources that are
shown in the search view freezes Eclipse for many minutes. With this
change the freeze is only about 30 seconds.

See eclipse-platform#2279
elsazac pushed a commit to elsazac/eclipse.platform.ui that referenced this issue Nov 8, 2024
…he tree mode

This change unifies "filter" label handling for tree/table mode in the
file search, we show now that the matches are filtered in both cases.

See eclipse-platform#2279
elsazac pushed a commit to elsazac/eclipse.platform.ui that referenced this issue Nov 8, 2024
If the search view has matches for 100.000 files, it would hang forever
on updating the view via F5 because it asks getMatchCount() for every
element and that traverses entire result again and again.

This change remembers last computed result and returns that value if
there were no further changes on the search result itself.

See eclipse-platform#2279
elsazac pushed a commit to elsazac/eclipse.platform.ui that referenced this issue Nov 8, 2024
If the search view shows ~100000 matches, deleting resources that are
shown in the search view freezes Eclipse for many minutes. With this
change the freeze is only about 30 seconds.

See eclipse-platform#2279
elsazac pushed a commit to elsazac/eclipse.platform.ui that referenced this issue Nov 8, 2024
If the search view shows ~100000 matches, deleting resources that are
shown in the search view freezes Eclipse for many minutes. With this
change the freeze is only about 30 seconds.

See eclipse-platform#2279
elsazac pushed a commit to elsazac/eclipse.platform.ui that referenced this issue Nov 8, 2024
If the search view shows ~100000 matches, deleting resources that are
shown in the search view freezes Eclipse for many minutes. With this
change the freeze is only about 30 seconds.

See eclipse-platform#2279
elsazac pushed a commit to elsazac/eclipse.platform.ui that referenced this issue Nov 8, 2024
elsazac pushed a commit to elsazac/eclipse.platform.ui that referenced this issue Nov 8, 2024
This change unifies "filter" label handling for tree/table mode in the
file search, we show now that the matches are filtered in both cases.

See eclipse-platform#2279
elsazac pushed a commit to elsazac/eclipse.platform.ui that referenced this issue Nov 8, 2024
If the search view has matches for 100.000 files, it would hang forever
on updating the view via F5 because it asks getMatchCount() for every
element and that traverses entire result again and again.

This change remembers last computed result and returns that value if
there were no further changes on the search result itself.

See eclipse-platform#2279
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working performance
Projects
None yet
Development

No branches or pull requests

4 participants