This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 232266 - org.netbeans.swing.outline.Outline.sortAndFilter: LowPerformance took 33474 ms.
Summary: org.netbeans.swing.outline.Outline.sortAndFilter: LowPerformance took 33474 ms.
Alias: None
Product: platform
Classification: Unclassified
Component: Outline&TreeTable (show other bugs)
Version: 7.3
Hardware: All All
: P2 normal (vote)
Assignee: Martin Entlicher
Depends on:
Reported: 2013-07-04 13:20 UTC by Alexander Simon
Modified: 2016-12-09 10:57 UTC (History)
18 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 196705

nps snapshot (188.42 KB, application/nps)
2013-07-04 13:20 UTC, Alexander Simon
nps snapshot (17.62 KB, application/nps)
2013-07-23 08:12 UTC, Exceptions Reporter
nps snapshot (41.90 KB, application/nps)
2013-07-23 10:00 UTC, webfox

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Simon 2013-07-04 13:20:31 UTC
Build: NetBeans IDE 7.3.1 (Build 20130620-54c8e3c738d3)
VM: Java HotSpot(TM) Client VM, 23.21-b01, Java(TM) SE Runtime Environment, 1.7.0_21-b11

User Comments:
GUEST: clicked "Expand all nodes in search tree"

alexvsimon: find on folder

gorrus: doing something

Maximum slowness yet reported was 33474 ms, average is 15580
Comment 1 Alexander Simon 2013-07-04 13:20:35 UTC
Created attachment 136716 [details]
nps snapshot
Comment 2 Exceptions Reporter 2013-07-23 08:12:44 UTC
Created attachment 137599 [details]
nps snapshot

very slow
Comment 3 webfox 2013-07-23 10:00:46 UTC
Created attachment 137609 [details]
nps snapshot

No clue, did some project searches for <a href="
Comment 4 Martin Entlicher 2013-07-24 12:16:12 UTC
The sorting was already optimized in issue #199600.
1) it might not be enough
2) it's an overkill to repeat the sorting every time selected rows are changed.
Comment 5 Martin Entlicher 2013-07-24 15:04:11 UTC
2) The sorting is performed after lines are inserted into the table, as a result of node expansion. To improve the performance, sorting permutation array can be shifted and only the expanded portion can be sorted.
When a node is collapsed, no sorting is necessary at all, the adjustment of sorting permutation array should be sufficient.
Comment 6 Alexander Simon 2015-12-16 08:46:58 UTC
170 reports => P1
Comment 7 Martin Entlicher 2015-12-17 13:46:27 UTC
I wouldn't say P1, the issue is there for a long time already and it "only" takes a long time, though the times >20s are really long.

I agree that it should be finally fixed.
Comment 8 Martin Entlicher 2015-12-18 15:56:01 UTC
It looks like all reports are from search results.
To reproduce, search for something with a lot of results and click on the File header to sort the results by file name in the middle of the search process.
There's a lot of tableChanged() events and corresponding sorting.
Comment 9 Martin Entlicher 2015-12-18 19:24:48 UTC
It seems is it the AbstractSearchResultsPanel, which is forcing Outline to expand too many nodes. Unfortunately, when nodes that are not part of the layout are expanded, it's causing excessive refreshes.
It'd be nice to adapt Outline/ETable to better handle this situation, but AbstractSearchResultsPanel can be optimized as well not to expand nodes multiple times.
Comment 10 Martin Entlicher 2015-12-18 19:26:11 UTC
After it's fixed, it's a good candidate for a patch.
Comment 11 Martin Entlicher 2016-09-01 15:22:50 UTC
Jarda, do you think that the search result panel can be modified to produce less expansions?