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 60885 - Project customizer opening is very slow
Summary: Project customizer opening is very slow
Status: VERIFIED FIXED
Alias: None
Product: apisupport
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Martin Krauskopf
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2005-07-12 14:47 UTC by _ rkubacki
Modified: 2005-11-29 12:29 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2005-07-12 14:47:37 UTC
I am using recent dev build & JDK 1.5.0_04 (PentiumM1.7GHz notebook with 1GB RAM)

First opening of project properties window takes a lot of time (often 5-10
seconds). Next usages are reasonably fast.
Comment 1 _ rkubacki 2005-07-14 14:38:11 UTC
80% of time spent in CustomizerProviredImpl.showCustomizer() is in
SingleModuleProperties.reloadModulesList() called from
CustomizerDisplay.<init>() -> ... fillUpCategory(). And here he biggest consumer
is TreeSet.add() where ModuleDependecy.compareTo takes the time because we go to
ModuleList.loadBundleInfoFromBinary() that creates JAR FS and looks for file
object containing the localized name. Note that there is a comment at this
method: 'XXX Similar (and better) code is in the
NbModuleProject.findLocalizedBundlePath()'. 

Also I have sources for all these modules that are in platform. Of course we
would have to check if it is faster to browse the disk to find these files than
to open all the JARs in target platform using JAR fs.

Comment 2 _ rkubacki 2005-07-14 14:50:08 UTC
We also initialize *all* the panels eagerly when the action is called. 
Comment 3 Jesse Glick 2005-07-14 20:35:03 UTC
Using JarFileSystem for this purpose is quite wasteful. Just use JarFile
directly, it is pretty fast. LocalizedBundleInfo.load should accept an
InputStream, not a FileObject.
Comment 4 Martin Krauskopf 2005-07-18 17:08:16 UTC
Thanks for the nice analysis. I'll try to refactor the code a little with the
yours tips in mind.
Comment 5 Martin Krauskopf 2005-07-19 23:40:39 UTC
I've just commited the patch which refactored the whole apisupport/project code,
used to handle localizing bundle, into one place. This in turn applied Jesse's
tip with getting rid of JarFileSystem which speeds up reload
SingleModuleProperties.reloadModuleListInfo() approximately two times. Second
reload:

    [junit] Reloading of module list: 928msec
    [junit] Reloading of module list: 475msec

It is really tricky to test the first time call since OS will cache needed data
between inidividual JVM invocations, but approximate result on my machines was
enhanced from cca 9 to cca 4-5 second.

Checking in o.n.m.a.p.NbModuleProject.java (1.89 --> 1.88)
Checking in o.n.m.a.p.NbModuleProjectGenerator.java (1.27 --> 1.26)
Checking in o.n.m.a.p.Util.java (1.15 --> 1.14)
Checking in o.n.m.a.p.ui/customizer/CustomizerDisplay.java (1.16 --> 1.15)
Checking in o.n.m.a.p.ui/customizer/CustomizerProviderImpl.java (1.30 --> 1.29)
Checking in o.n.m.a.p.ui/customizer/ModuleProperties.java (1.4 --> 1.3)
Checking in o.n.m.a.p.ui/customizer/SingleModuleProperties.java (1.9 --> 1.8)
Checking in o.n.m.a.p.universe/AbstractEntry.java (1.3 --> 1.2)
Checking in o.n.m.a.p.universe/LocalizedBundleInfo.java (1.2 --> 1.1)
Checking in o.n.m.a.p.universe/ModuleList.java (1.8 --> 1.7)
Checking in test/o.n.m.a.p.UtilTest.java (1.2 --> 1.1)
Checking in test/o.n.m.a.p.ui/customizer/SingleModulePropertiesTest.java (1.4
--> 1.3)

(leaving open since the first invocation is still slow and also this was rather
refactofing phase then optimization phase)
Comment 6 Martin Krauskopf 2005-07-19 23:44:18 UTC
Previous post could be confusing. I wanted to write

The second call to SingleModuleProperties.reloadModuleListInfo takes:

- before patch: 928msec
- after patch: 475msec
Comment 7 Martin Krauskopf 2005-09-12 12:27:56 UTC
I'll continue on this. I'll make Libraries Panel lazy-loaded with "Loading data
from target platform" (or whatever), plus disabling appropriate components (like
add new dependency), until data is loaded. This should give the user immediate
feedback when goes to the properties first time.

Or anybody has better idea (like preloading needed data in separate thread when
project is opened in NbModuleProject constructor - drawback is that user could
never go to the module's properties), or...
Comment 8 Antonin Nebuzelsky 2005-09-13 10:12:43 UTC
> I'll make Libraries Panel lazy-loaded with "Loading data from target platform"
> (or whatever), plus disabling appropriate components (like add new dependency),
> until data is loaded.

Good.

> Or anybody has better idea (like preloading needed data in separate thread
> when project is opened in NbModuleProject constructor...

Please, dont' do that.
Comment 9 Martin Krauskopf 2005-09-22 08:31:45 UTC
Fixed. Everything is safely lazy-loaded now.

Checking in ui/customizer/AddModulePanel.java; 1.18 --> 1.19
Checking in ui/customizer/ComponentFactory.java; 1.36 --> 1.37
Checking in ui/customizer/CustomizerDisplay.java; 1.22 --> 1.23
Checking in ui/customizer/CustomizerLibraries.java; 1.33 --> 1.34
Checking in ui/customizer/ModuleProperties.java; 1.6 --> 1.7
Checking in ui/customizer/SingleModuleProperties.java; 1.27 --> 1.28
Checking in ui/wizard/action/GUIRegistrationPanel.java; 1.7 --> 1.8
Comment 10 Marian Mirilovic 2005-11-29 12:29:26 UTC
   NB Project Properties window open
   [ ms ] / 1000 ms 	LC3     Sol9    Sol10   W2K     WXP
      1st usage 	841 	696 	1533 	364 	536
Subsequent usage 	266 	218 	189 	109 	124

verified in NB 5.0 (200511281900)