Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 134555 - Expanding java packages list is slow
Expanding java packages list is slow
Product: java
Classification: Unclassified
Component: Project
All All
: P3 (vote)
: 6.x
Assigned To: Tomas Zezula
Depends on:
  Show dependency treegraph
Reported: 2008-05-06 03:13 UTC by Jaroslav Tulach
Modified: 2010-05-05 12:47 UTC (History)
12 users (show)

See Also:
Issue Type: DEFECT

Patch, tests in java.project work, code is java.j2seproject is just a sketch (23.55 KB, patch)
2008-05-06 03:20 UTC, Jaroslav Tulach
Details | Diff
Necessary changes in java.source (9.10 KB, patch)
2008-06-05 12:48 UTC, Jan Lahoda
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2008-05-06 03:13:56 UTC
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:
Comment 1 Jaroslav Tulach 2008-05-06 03:20:12 UTC
Created attachment 61064 [details]
Patch, tests in java.project work, code is java.j2seproject is just a sketch
Comment 2 Jan Becicka 2008-05-16 13:31:40 UTC
Milane, do you work on this?
Comment 3 Milan Kubec 2008-05-16 13:54:17 UTC
No, I work on tasks planned for 6.5, see:
Comment 4 Jaroslav Tulach 2008-06-04 14:16:26 UTC
I guess now the work is on the shoulder of Jan. Please try to use the API in the patch.
Comment 5 Jan Lahoda 2008-06-05 12:45:34 UTC
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.
Comment 6 Jan Lahoda 2008-06-05 12:48:27 UTC
Created attachment 62408 [details]
Necessary changes in java.source
Comment 7 Jaroslav Tulach 2008-06-13 16:48:30 UTC
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.
Comment 8 Rich Unger 2008-06-14 00:00:38 UTC
So, my 600 package node took 10-12 seconds before these patches, and 3-4 seconds after.  Nice.
Comment 9 Jaroslav Tulach 2008-06-14 05:05:49 UTC
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 
Comment 10 carniz 2008-08-28 17:18:09 UTC
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 with 75 classes, expansion time after cold start: 2 minutes 43s (!)
* The package with 13 classes, expansion time after cold start: 41s
* The package with 9 classes, expansion time after cold start: 28s
* The package 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.
Comment 11 mutchd 2008-09-04 03:32:44 UTC
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.
Comment 12 Jaroslav Tulach 2008-09-04 13:25:23 UTC
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.
Comment 13 Jan Lahoda 2008-09-07 17:50:31 UTC
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).
Comment 14 Jan Lahoda 2008-09-24 12:49:48 UTC
See above.
Comment 15 Jan Becicka 2008-11-13 15:48:32 UTC
This can be fixed by new indexing (provided directory structure is stored in index)
Comment 16 David Strupl 2010-05-05 12:47:54 UTC
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.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo