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 41072 - Opening first file in editor is slower with new build system
Summary: Opening first file in editor is slower with new build system
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Miloslav Metelka
Depends on:
Blocks: 41535
  Show dependency tree
Reported: 2004-03-17 15:11 UTC by Antonin Nebuzelsky
Modified: 2007-11-05 13:44 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Screenshot of jprofiler's call tree window (170.33 KB, image/png)
2004-06-03 09:25 UTC, Antonin Nebuzelsky

Note You need to log in before you can comment on or make changes to this bug.
Description Antonin Nebuzelsky 2004-03-17 15:11:39 UTC
There is a significant performance regression in
trunk in opening a file in the editor after the
new BuildSys was integrated.

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) Opening as a first file after start

200403141900 - 1312ms, 1250ms, 1266ms
200403161900 - 1875ms, 1860ms, 1859ms

200403141900 - 1262ms, 1692ms, 1191ms
200403161900 - 2180ms, 2066ms, 1729ms

2) Opening after the IDE starts with
a already open in the editor

200403141900 - 1078ms, 859ms, 922ms
200403161900 -  938ms, 953ms, 719ms

200403141900 -  989ms,  995ms, 1041ms
200403161900 - 1046ms, 1813ms,  954ms
Comment 1 Tomas Zezula 2004-06-02 09:20:14 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 2 Antonin Nebuzelsky 2004-06-02 15:51:35 UTC
The same configuration, last trunk build before merge of refactoring.

1) Opening as a first file after start

200406011800 - 1797ms, 1719ms, 1609ms

200406011800 - 2946ms, 2870ms, 3019ms

2) Opening after the IDE starts with
a already open in the editor

200406011800 - 610ms, 563ms, 594ms

200406011800 - 866ms, 864ms, 854ms

Assigning the bug to myself. I will have a look at the first opening
of java file in profiler.
Comment 3 Antonin Nebuzelsky 2004-06-03 09:24:21 UTC
Tomasi, great portion of the first file opening time is spent in
JCFinderFactory.getFinder() and in JCBaseFinder.getExactPackage(), see
the attached call tree from profiler.
Comment 4 Antonin Nebuzelsky 2004-06-03 09:25:24 UTC
Created attachment 15448 [details]
Screenshot of jprofiler's call tree window
Comment 5 David Konecny 2004-06-03 10:32:22 UTC
The JCFinderFactory was removed during MDR merge and JCBaseFinder can
now behave completely different.
Comment 6 Jesse Glick 2004-06-03 22:37:45 UTC
In general, throw out any performance data you might have had
regarding the editor, parser database, etc., since it is all quite
different after the refactoring merge.
Comment 7 Tomas Zezula 2004-06-07 15:48:40 UTC
According to the JProfiler screenshot it seems that the most time is
spent in the editor module.
But the JCClass stuff was completely redesign, probably the bug is
Comment 8 Martin Roskanin 2004-06-08 07:36:42 UTC
Yes. This issue can be closed. The main performance problem was caused
by creation of JCBaseFinders, where parserDB files were read from disk
and memory parserDBs were created. This took 1600ms. Parser DB files
were replaced by MDR, behaviour is different.
Comment 9 Antonin Nebuzelsky 2004-06-09 18:03:00 UTC
OK, forget this bug.
I have entered a fresh one ;-)
See issue 44661.