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 145851 - long pauses when using "Go To Type..."
Summary: long pauses when using "Go To Type..."
Status: RESOLVED FIXED
Alias: None
Product: obsolete
Classification: Unclassified
Component: visualweb (show other bugs)
Version: 6.x
Hardware: Sun All
: P3 blocker (vote)
Assignee: _ potingwu
URL:
Keywords: PERFORMANCE
Depends on: 146618
Blocks:
  Show dependency tree
 
Reported: 2008-09-02 05:31 UTC by nleck
Modified: 2008-09-16 16:55 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
five ctrl-\ while IDE was locked up (122.62 KB, text/plain)
2008-09-02 05:32 UTC, nleck
Details

Note You need to log in before you can comment on or make changes to this bug.
Description nleck 2008-09-02 05:31:31 UTC
The search appears to be blocked while the back ground compile runs ( can take minutes). After the back ground compile 
has finished the list of matching classes are shown. Clicking on one of these classes can lock up the IDE for many 
seconds before opening the source file.
Comment 1 nleck 2008-09-02 05:32:35 UTC
Created attachment 68822 [details]
five ctrl-\ while IDE was locked up
Comment 2 Jan Becicka 2008-09-04 09:42:55 UTC
The first part of the issue is already reported, the second part is related to JSF.

Comment 3 _ potingwu 2008-09-04 16:49:38 UTC
It's again the jsfloader/isJsfProjectFile issue! Quy, could you please take a look whether it's new or not? Thanks!
 
	at org.netbeans.modules.visualweb.project.jsf.api.JsfProjectUtils.isJsfProjectFile(JsfProjectUtils.java:266)
	at org.netbeans.modules.visualweb.project.jsfloader.JsfJavaDataLoader.findPrimaryFile(JsfJavaDataLoader.java:138)
Comment 4 Quy Nguyen 2008-09-04 18:48:13 UTC
The 'isJsfProjectFile' method checks every parent directory of the source file to attempt to find a matching project
directory.  On Windows, this can be rather slow.  I'm not sure what can be done about it from the jsfloader side.
Comment 5 _ potingwu 2008-09-04 19:03:21 UTC
'isJsfProjectFile' is only been called by jsfloader which has the potential performance issue. The method itself has no
room to improve as we already tried for a long developing time. To improve further, looks like the only way is to change
the jsfloader's strategy.

Actually this method 'isJsfProjectFile' should move to jsfloader module because no other codes are using it!
Comment 6 _ potingwu 2008-09-04 19:22:25 UTC
Quy, is it possible the jsfloader only checks the JSP files without looking at the Java files?

The huge performance issue is mostly caused by the large number of Java files (e.g., developing NetBeans). However
Visual Web projects usually do not have many Java files need to be checked. When jsfloader.JSP loader starts, it found
the paired Java file. Is that enough to make the IDE recognize these multi-files pairs. And then we can remove the
jsfloader.Java loader to do the similar check again.

As I checked, both jsfloader.JSP and jsfloader.Java call 'isJsfProjectFile'. And when I working on NetBeans, I found
most of calls are coming from jsfloader.Java loader with the extension 'java'.
Comment 7 Quy Nguyen 2008-09-04 22:57:11 UTC
The jsfloader looks at java files for exactly one reason - when the user attempts to open a java file that is associated
with a jsf page, the designer opens with the java tab selected.  This doesn't happen necessarily after the jsfloader
sees the corresponding jsp files, so the proposed solution will not work.

What we should probably do is annotate the java file (maybe with a comment in a guarded block) with the relative path of
the jsp so we don't have to perform an expensive filesystem search to determine whether it is a page bean.  However,
this would require that we update all the page bean java files when opening old projects.  This is a fairly involved
task that I don't think can be done for 6.5.
Comment 8 nleck 2008-09-04 23:08:20 UTC
In our case we have NO jsf or jsp files at all. Is there a module that we can disable to make it go faster as a workaround ?
Comment 9 _ potingwu 2008-09-04 23:35:05 UTC
If the only purpose of jsfloader.Java is to allow user to 'open' the multi-view, then we may need to consider disabling
it. I believe most users use the JSP page node to bring up the multi-view. Even double click on the Java node will only
show the single-view, I think it's still acceptable.

If this issue caused too much performance trouble to the whole IDE, I think the management level may need to decide
whether we disable the jsfloader.Java part or not.
Comment 10 Quy Nguyen 2008-09-05 00:52:35 UTC
Disabling/uninstalling the "Visual JSF" module in the Tools->Plugins manager should do the trick.

As for changing the jsfloader to not accept java files when the corresponding jsp isn't opened, that is a rather major
change that will probably have undesirable side effects.
Comment 11 _ potingwu 2008-09-16 00:24:21 UTC
Fixed in the 6.5 trunk,
    changeset c563c77785bd in main
    details: http://hg.netbeans.org/main?cmd=changeset;node=c563c77785bd

The cache has been improved for project created by 'Existing Sources'. Please try build#3780 or later to see whether it
resolve your issue or not. Thanks!

BTW, were your projects created by 'Existing Sources'?
Comment 12 nleck 2008-09-16 01:10:56 UTC
Yes, this project was created from an existing source tree.

It is a freeform project too. 
Comment 13 _ potingwu 2008-09-16 16:55:31 UTC
> Please try build#3780 or later to see whether it resolve your issue or not. Thanks!

BTW, for the public daily build, please use build *200809160201* or later. Thanks!