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.
Created attachment 68822 [details]
five ctrl-\ while IDE was locked up
The first part of the issue is already reported, the second part is related to JSF.
It's again the jsfloader/isJsfProjectFile issue! Quy, could you please take a look whether it's new or not? Thanks!
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.
'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!
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'.
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.
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 ?
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.
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.
Fixed in the 6.5 trunk,
changeset c563c77785bd in main
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'?
Yes, this project was created from an existing source tree.
It is a freeform project too.
> 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!