BeanTreeView has a low perfomance becouse sequential search in collections are used.
See attached stack trace for operations.
Created attachment 52973 [details]
Expanding nodes takes a lot of time.
Created attachment 52974 [details]
Finding node takes a lot of time.
Created attachment 52975 [details]
Setting new content takes a lot of time.
Well, 2 of 3 cases are actually JTree problems. Still, it is strange JTree keeps using VariableHeightLayoutCache, where
TreeView.ExplorerTree sets fixed cell height.
Generally, as long as the time is O(N), it shouldn't be a big deal. If you see O(N^2), it is certainly a big problem.
How many nodes do you have?
Bug is show stopper for Open Solaris project.
Default namespace has about 250K nodes (variables, structs and functions).
TreeView (or any nodes-based view) is very far from being _that_ scallable.
On the other hand, how practical is a list-like* visualization of so many items for the user?
*) Do I understand it correctly that you're trying to display so many entries at once, i.e. in a flat tree or very few
Open Solaris has at least 150K top level nodes in the default namespace.
Yes, user expand namespace with 150K top level nodes.
Of course, some of nodes has children nodes (structs, enums, classes).
How practical? I do know how user uses class view,
but it is an industrial standard for IDE that support c/c++.
Reassigning to new module owner Tomas Holy.
changing this issue into planning issue for 6.5. Please, change the TM
I guess it is time to ask for review. Given the quick turn around between this announcement and integration, I think
we'd rather call standard review tomorrow. Reviewers: jtulach, jglick, pnejedly, jlahoda. Review conf call: Thu Jul
10, 15.00CET. I'll send the details later. OK?
Approved with TCRs. Will be integrated tomorrow. Here is the result of review:
Any reason this is not marked FIXED yet?
*** Issue 114195 has been marked as a duplicate of this issue. ***