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 41078 - Fast open and open from To Do window are extremely slow
Summary: Fast open and open from To Do window are extremely slow
Status: CLOSED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Infrastructure (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Tomas Zezula
URL:
Keywords: PERFORMANCE, REGRESSION
Depends on:
Blocks: 41535
  Show dependency tree
 
Reported: 2004-03-17 16:10 UTC by Antonin Nebuzelsky
Modified: 2006-03-24 09:43 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Thread Dump when opening a java file w/ code-folding turned on. (20.57 KB, text/plain)
2004-04-19 14:45 UTC, Antonin Nebuzelsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Antonin Nebuzelsky 2004-03-17 16:10:52 UTC
There is a significant performance regression in
trunk in fast open for a file after the new
BuildSys was integrated. Unlike the issue 41072,
the regression of fast open is significant when
some files are already open in the editor. So this
is a different problem than issue 41072.

Notice that the regression is measureable for
JTable.java, but not for Main20kB.java (which is
in my small local FS).

Here are results from testing on W2K (Dell
Precision 220, PIII 800MHz, 512MB RAM, Windows
2000) and Linux (Dell Latitude C840, PIV 2.2GHz,
1024MB RAM, Red Hat 9). Each test was repeated
three times.

1) Fast opening JTable.java after the IDE starts
with a Main.java already open in the editor

W2K:
200403141900 - 3281ms, 3141ms, 3344ms
200403161900 - 5296ms, 5188ms, 5093ms

Linux:
200403141900 - 4026ms, 4157ms,  4022ms
200403161900 - 8186ms, 5573ms, 10806ms

2) Fast opening Main20kB.java after the IDE starts
with a Main.java already open in the editor

W2K:
200403141900 - 984ms, 1032ms, 750ms
200403161900 - 922ms,  796ms, 938ms

Linux:
200403141900 - 2215ms, 1489ms, 1822ms
200403161900 - 1916ms, 1637ms, 1641ms
Comment 1 Antonin Nebuzelsky 2004-04-09 16:01:57 UTC
The slowish opening of java file is not happing only with fast open
(ALT+SHIFT+O), but also with the "Show selected TODO in editor"
functionality of To Do window.

For example for the file org.netbeans.core.xml.EntityCatalogImpl fast
opening via ALT+SHIFT+O takes 17 seconds on my W2K machine, while
opening from To Do window takes 18 seconds. Opening this file straight
from the Projects tab directory structure takes around 3 seconds
(doing it as the first thing after IDE start).
Comment 2 Jesse Glick 2004-04-14 01:32:56 UTC
Opening EntityCatalogImpl takes less than a second on my machine. With
code folding turned off. Have you tried w/ and w/o code folding?
Comment 3 Antonin Nebuzelsky 2004-04-19 14:44:57 UTC
W/ the codefolding. When you turn the code-folding off, opening files
is fast. In the thread dump (see attached) you can see that
FoldMaintainer invokes parser which perhaps takes all the time. But
why it takes soooo long?

Mila, your turn. ;o)
Comment 4 Antonin Nebuzelsky 2004-04-19 14:45:57 UTC
Created attachment 14460 [details]
Thread Dump when opening a java file w/ code-folding turned on.
Comment 5 Jesse Glick 2004-04-19 17:17:52 UTC
At least in this thread dump, FileUtil.isArchiveFile is taking the
time. Of course this is just a random snapshot.
Comment 6 Miloslav Metelka 2004-04-27 13:58:01 UTC
Well what we may try for testing purposes is to do nothing in
FoldMaintainer.initFolds() and leave the folds creation for later -
when someone else (e.g. NavigationView) asks for reparse which will
notify the editor (or the editor may ask for reparse lazily as well).
I'll try to experiment with that.
Comment 7 Tomas Zezula 2004-06-02 09:20:39 UTC
The only additional overhead introduced by new build system is time
spent in queries. The queries was significantly improved.
Could someone perform new analyzes on build without refactoring?
Comment 8 Antonin Nebuzelsky 2004-06-02 19:10:49 UTC
New numbers with the same configuration, last trunk build before merge
of refactoring.

1) Fast opening JTable.java after the IDE starts
with a Main.java already open in the editor

W2K:
200406011800 - 3875ms, 4329ms, 4250ms

Linux:
200406011800 - 4310ms, 4734ms, 6816ms

2) Fast opening Main20kB.java after the IDE starts
with a Main.java already open in the editor

W2K:
200406011800 - 844ms, 937ms, 797ms

Linux:
200406011800 - 1134ms, 925ms, 982ms

This means that fast opening Main20kB.java from my project's src is
not a regression at all. An issue is still fast opening classes from
JDK's sources.
Comment 9 Tomas Zezula 2004-06-03 09:40:54 UTC
Seems that the performance optimalization of ClassPath and queries
helped. There is no regression for project files and the regression
for JDK files is lower.
The question is what part of the regression is related to build system?
Tondo, could you measure some hot spots of the fast open?
Comment 10 Antonin Nebuzelsky 2004-06-03 09:42:57 UTC
Yeah, I am looking into it.
Comment 11 Tomas Zezula 2004-07-15 14:42:54 UTC
I've look on it in the OptimizeIt and I haven't find a problem related
to the BuildSystem.
The original slow down of the open was caused by queries  and classpath.
All these issues were fixed. Biggest regression was in the queries,
all queryImpls was used. This has changed and FileUtil.isArchiveFile
was removed from ClassPathProviders. Also the queriesImpls and
CLassPathProviders were ordered.
Comment 12 Marian Mirilovic 2005-11-29 10:57:39 UTC
verified in NB5.0 (200511281900)

To Do window open   [ ms ] / 1000 ms 	
1st usage 	872 	1125 	972 	531 	770
Subsequent usage 	311 	277 	257 	109 	156