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 52632 - Slow node expanding of libs and test libs in J2SE project
Summary: Slow node expanding of libs and test libs in J2SE project
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 4.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: Tomas Zezula
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2004-12-17 20:48 UTC by _ rkubacki
Modified: 2005-01-10 17:35 UTC (History)
2 users (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 2004-12-17 20:48:27 UTC
dev build from Dec 17, JDK5.0

Newly added nodes for Libraries and Test Libraries
show elements from execution and testing classpath
but expanding of these nodes is slow. 

This is especialy true for rt.jar node expanding.
rt.jar contains a lot of entries that are grouped
into packages view and then presented.

Another case is expanding of package content. It
possible that this is slow because we use differnt
icon for classes that are supposed to be bean and
another icon for the rest of classes (+ badges for
executable classes).
Comment 1 _ rkubacki 2004-12-17 21:02:18 UTC
Some numbers from my Dell notebook (P4 2GHz, 1GB, Linux FC2, JDK5.0u1-b06)

first expand of rt.jar node 7.3s
first expand of junit node 0.5s (OK)
expanding of junit.framework package 2.2s
expanding of java.awt package 17.5s
expanding of java.beans package 5s

first expand of rt.jar node in 2nd project 5.3s
first expand of junit node in 2nd project 0.1s (OK)
expanding of junit.framework package in 2nd project 0.5s
expanding of java.awt package in 2nd project 0.5s

It means that package opening is pretty slow and even when it is
displayed there is still some activity running after first open that
causes next repaints (event firing?)

Comment 2 _ rkubacki 2004-12-21 13:58:28 UTC
re packages expanding: 
the time is spent in PackageViewChildren.run -> %75 computeKeys & %35
refreshKeys. 
- computeKeys iterates through all entries in JarFS. We check
timestamp for each AFO created and schedule closing of jar file. 20%
is also in VisiblityQuery.isVisible (regexp matching). I am adding
Radek to cc, maybe he can suggest some improvements in JarFS.
- refreshKeys - creating of nodes (finding DOs), galls to getCookie
and lookup unpdating.
Then we get back to AWT to display packages. Here we can perhaps save
some time in getIcon - we do check if package is publicly accessible
for every package. This involves FileOwerQuery execution and than
check if there is AccessibilityQuery.

Comment 3 _ rkubacki 2004-12-21 15:08:10 UTC
re package content expanding:

ClassDataNode.<init> -> 
ClassDataNode.initialize ->
ClassDataObject.getSource ->
org.openide.src.SourceElement.<init> 

and the elements are eagerly initalized. This is really heavy task and
forces full GC and couple of minor GCs.

Icon resolving is really postponed at least on Solaris until the
computation of nodes is done but probably it will be worse on Linux.
Comment 4 Tomas Zezula 2005-01-04 15:53:17 UTC
I am trying to delay the parsing of the classfile which slows down the
folder expansion.
Comment 5 Tomas Zezula 2005-01-10 17:35:39 UTC
Checking in src/org/netbeans/modules/clazz/ClassDataNode.java;
/cvs/clazz/src/org/netbeans/modules/clazz/ClassDataNode.java,v  <-- 
ClassDataNode.java
new revision: 1.47; previous revision: 1.46
done
RCS file:
/cvs/clazz/src/org/netbeans/modules/clazz/LazySourceChildren.java,v
done
Checking in src/org/netbeans/modules/clazz/LazySourceChildren.java;
/cvs/clazz/src/org/netbeans/modules/clazz/LazySourceChildren.java,v 
<--  LazySourceChildren.java
initial revision: 1.1
done