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.
Open J2SE project that has few packages and a lot of files. Wait till parsing is over. Expand the packages node in logical view. It takes ages. It should not, the information has already been gathered from the disk and is kept somewhere in Java parsing infrastructure. Please reuse it. I am going to attach preview patch for the API:
Created attachment 61064 [details] Patch, tests in java.project work, code is java.j2seproject is just a sketch
Milane, do you work on this?
No, I work on tasks planned for 6.5, see: http://wiki.netbeans.org/PostSixOhCoreAndPlatformTopics.
I guess now the work is on the shoulder of Jan. Please try to use the API in the patch.
I am attaching an impl. of the PackagesProvider based on the java.source's index. It is not fully functional (does not check whether the RU is running or not, newly added packages are not handled correctly, etc., etc.), but should be enough to test whether this change will improve the situation. What needs to be done now: 1. evaluate the impact - not only using the tests, but also from the user's point of view. Is the improvement big enough to sustain the work? Won't the change affect other parts of the IDE negatively? 2. finalize the SPI (one question: who and how listens on the FS events? When exactly will be the compute method called?) Also, provide a way to test the PackagesProviders. 3. finalize the java.source's provider. My work, IMO is to do 3. and provide feedback on 2., assigning back to Jarda.
Created attachment 62408 [details] Necessary changes in java.source
Looks like Rich is interested in speed of expansion of Source Packages node: > I just built the trunk and tried out our codebase. I > hadn't tried this for several weeks. This time, the performance was > much improved. Particularly, the performance of opening a source root > node with about 600 packages in it. It doesn't feel instantaneous, > but it's just a few seconds, compared to "go get a cup of tea and come > back". I'm guessing you had something to do with that, so thanks! We did improved the speed by recent data loader changes. However we have potentially even better improvement. Rich would you be so kind to apply the two patches attached to this issue and tell us if it gets even better? If so, we can really integrate this improvement, if not, we can discard these changes.
So, my 600 package node took 10-12 seconds before these patches, and 3-4 seconds after. Nice.
Milan, Jan, I guess Rich's measurement is real enough to convince you to implement this feature. Step 1. is done. Now onto to 2. - probably let's start Jan providing coments and Milan fulfiling them then. Jan, please do so early next week.
I see very long waits here as well - it can even take minutes to expand a package in some cases (see below). My setup: * Dell Latitude D620, Intel Core2 Duo T5500, 2Gb Ram * Windows XP version 5.1 running on x86; Cp1252; sv_SE (nb) * NetBeans IDE 6.5 Beta (Build 200808111757) * netbeans_jdkhome="C:\Java\jdk1.6.0_03" * netbeans_default_options="-J-Dorg.glassfish.v3.installRoot=\"C:\appservers\glassfish-v3-prelude-b15b\" -J-Dcom.sun.aas.installRoot=\"C:\appservers\glassfish-v2\" -J-client -J-Xverify:none -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m -J-Dnetbeans.logger.console=true -J-ea -J-Dapple.laf.useScreenMenuBar=true -J-Dsun.java2d.noddraw=true -J-Dswing.aatext=false" * Freeform project with 52 packages, 475 classes Timing examples: * The package foo.bar.model with 75 classes, expansion time after cold start: 2 minutes 43s (!) * The package foo.bar.impl with 13 classes, expansion time after cold start: 41s * The package foo.bar.billing with 9 classes, expansion time after cold start: 28s * The package foo.bar.listener with 1 class, expansion time after cold start: 3s This makes it downright painful to use NB...please look into it, I don't think this an abnormally large project so there should be more developers than me who would appreciate a performance improvement in this area.
I see similar performance metrics as carniz on my dual Xeon 3Ghz with 3.25 GB of ram. This makes finding files manually painful, but also find in projects is badly affected. Would really appreciate a speed up here.
I am afraid we are seeing symptoms of issue 144131 in mutchd and carniz comments. Guys, if you can help us profiling, as described in comment "Additional comments from jtulach Tue Sep 2 14:28:43 +0000 2008", then we'll fix your problem.
I think there are two independent reports here: -the original one speaks about reusing information gathered during Java scan to speedup creation of the package nodes (not the nodes under the package nodes) of the package view. I do not think this is feasible for 6.5 (unless we are ready to face the possible functional regressions). -the mutchd and carniz comments: either duplicate of issue 144131 (as jtulach wrote), or a new problem, in which case a new report should be created (java/project, owner mkubec).
See above.
This can be fixed by new indexing (provided directory structure is stored in index)
This has been here for too long. I am afraid that any patches would have to be re-done in the current sources. I am marking this as incomplete. If we want someone to work on this please provide profiler snapshots from the situation when it is slow so we can see where is the problem to be fixed.