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.
Status: STARTED
Alias: None
Product: platform
Classification: Unclassified
Component: Outline&TreeTable (show other bugs)
Version: 7.3
Hardware: All All
: P2 normal (vote)
Assignee: Martin Entlicher
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
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

Attachments
nps snapshot (188.42 KB, application/nps)
2013-07-04 13:20 UTC, Alexander Simon 		Details
nps snapshot (17.62 KB, application/nps)
2013-07-23 08:12 UTC, Exceptions Reporter 		Details
nps snapshot (41.90 KB, application/nps)
2013-07-23 10:00 UTC, webfox 		Details
Add an attachment (proposed patch, testcase, etc.)

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
OS: SunOS

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?