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.
Is does all sub-comparisons in advance and then computes complex return value, while only the sign of the value is important. The comparator should be structured to return immediatelly after each comparison step whereever is it possible. Moreover, it accesses some values from MDR during comparison, which is very slow to be performed log(N) times for each element instead of once. Some caching scheme is needed there.
*** Issue 53045 has been marked as a duplicate of this issue. ***
Dafe, after our discussion about importance of this issue, I still believe this is an important one. I think we should make the following scenario fast and responsive: navigating in Explorer, selecting nodes of Java classes, looking at list of their members in Navigator and eventually navigating to the members by clicking in Navigator. And this particular scenario requires Navigator to show its contents as fast as possible.
OK, I respect your opinion while I still disagree. For sure I'll take a look on this bug before high resistance. Even better if perf team could come with a patch.
A bit of VOC supporting my opinion. ;o) I saw this today in an email from someone outside of Netbeans: "Since we're here, is Navigator getting any faster? It takes like 5 seconds for it to build the list of members for large classes (like SunGraphics2D), and it doesn't appear to cache it, so it takes that long every time."
Created attachment 19630 [details] A micro-optimized patch
I'm with Dafe here. The attached patch produces pretty much the same results as the original method (there are some subtle differences for multiply nested classes), but includes several micro optimizations: 1. The number of JMI calls is minimized to 2. 2. Optimized workflow, shorter execution path, less tests. 3. No aritmetics. Still, I can hardly see any performance improvement when running with the patch and trying to populate Navigator with big classes such as JTable. It might be interesting to profile and compare the results. I agree that some caching strategy might help a little bit more, although I doubt it can bring a huge improvement.
> I agree that some caching strategy might help a little bit more, > although I doubt it can bring a huge improvement. If the sort takes 50% of the time then caching can help quite a lot as it can turn the number of JMI calls from O(N*log(N)) to O(N). But if the sort is not the major component of the time, improving the comparator can't help much.
My measurements on real running IDE (no profiler) showed me about 20% of time being spent in sorting AFAI remember. So caching will help IMO, but not that significantly.
Fixed in main trunk: /cvs/objectbrowser/navigator/javanavigation/src/org/netbeans/modules/javanavigation/ClassMemberComparator.java,v <-- ClassMemberComparator.java new revision: 1.2; previous revision: 1.1 Btw, as expected, no real big gain obtained, user will probably not see the speedup. But my measurements for JTable showed about 220ms of sorting using old method and about 90ms using new method. So percentage gain is enormous, but real gain is slightly over 100ms on my machine. Not earthshaking, but not bad. Thanks alot Honza for patch. (I just improved it a little, getName() seems to be faster then toString).