Community
Participate
Working Groups
Java Search throght JSP (some method search by References -> Project) is very slow. I have dynamic web project whis 12000 jsp files. And find usage of any method processing during 1-4 minutes throght JSP indexes. And never find any result in JSP. Only in java source code. Also very slow work any refactor operation under class or method.
Assuming I am reading this correctly there are no references to be found in the JSPs but they are still being searched. If this is the case there is now an option to disable searching JSP files when performing a Java search. Window -> Preferences -> Web -> JSP Files "Include JSP matches in Java searches" Based on this I vote to close.
Whis problem dublicate in 151689 bug. Which version was it in?
I am a bit confused, if you could help clarify it would be appreciated. Is your problem that there are no Java references to be found in your JSPs and you do not like that they are still all searched when doing a reference search. Or is the problem that there are references to be found in the JSP files be even after spending all that time searching the searcher does not find them? If your issue is the first issue then that is avoided by the preference described in comment #1 which is coming in WTP 3.2 If your issue is the second issue (similar to Bug 151689) then it should be cleared up by Bug 291659 which will also be in WTP 3.2
In order to summarize I see two kind of problems. 1)Java search is generally unable to find anything in JSPs 2)In certain cases when Java search finally finds some references, it takes great amount of time My current way to solve these problems in editting of org.eclipse.jst.jsp.ui_xxx\plugin.xml I disable the blocks below: <extension point="org.eclipse.jdt.ui.queryParticipants">...</extension> <extension point="org.eclipse.ltk.core.refactoring.renameParticipants">...</extension> <extension point="org.eclipse.ltk.core.refactoring.moveParticipants">...</extension> I'd like to make sure that your new option (of disabling the search in JSP files when performing a Java search) gives result I want. addition it'll be a great advantage if disabling of search in JSPs can disable JSP indexation too.
(In reply to comment #4) > I'd like to make sure that your new option (of disabling the search in JSP > files when performing a Java search) gives result I want. The result of unckecing the preference is akin to removing the query participant extension point, it disables that participant. Thus making it so that the JSP files are not searched for Java references. > addition it'll be a great advantage if disabling of search in JSPs can disable > JSP indexation too. We can not disable the index when the search is disabled because the index is used for more then just search, it is also used for other actions such as refactoring.
(In reply to comment #5) > The result of unckecing the preference is akin to removing the query participant > extension point, it disables that participant. Thus making it so that the JSP > files are not searched for Java references. It's clear. I realize that I had to disable participant in case I hadn't had these option before. > We can not disable the index when the search is disabled because the index is > used for more then just search, it is also used for other actions such as > refactoring. Meanwhile I've tested Eclipse 3.6 J2EE M4 a bit. Option of disabling the search in JSP files is good. However the search through JSPs is still quite slow (e.g. Java search takes 3-4 sec, JSP search takes 30-60 sec), to say nothing of stopping it(search) at all after Eclipse restart. So I'm trying to say that if the efficiency of search wasn't increase some additional option should be made to disable refactoring mode in JSP. As far as simple rename operation takes 35-65 sec (that is unacceptable) I will still have to disable proper participant extension point.
(In reply to comment #6) > Meanwhile I've tested Eclipse 3.6 J2EE M4 a bit. Option of disabling the search > in JSP files is good. However the search through JSPs is still quite slow (e.g. > Java search takes 3-4 sec, JSP search takes 30-60 sec), This slow down is probably mostly due to the cost of having to first translate the JSPs and then search through their translations. Bug 299423 was recently put into WTP 3.2 to persist these translations between sessions so that files that are not edited do not need to be re-translated for each search or refactor even after closing and opening a workspace. I would be curious if this speeds up your scenario. > ... to say nothing of > stopping it(search) at all after Eclipse restart. Not sure what you mean here. > So I'm trying to say that if the efficiency of search wasn't increase some > additional option should be made to disable refactoring mode in JSP. > As far as simple rename operation takes 35-65 sec (that is unacceptable) I will > still have to disable proper participant extension point. I personally do not see 35-65 seconds completely unreasonable to search through 12000 JSP files but looking for ways to speed things up is never a bad thing. There were some fixes that went into the refactoring in November (Bug 164263) though I don't know if that fix would help with the performance. What version of WTP are you running on? So just to clarify, the you would like the focus of this bug to speed up the time it takes for Java refactoring using the JSP participants compared to Java refactoring without them?
(In reply to comment #7) > This slow down is probably mostly due to the cost of having to first translate > the JSPs and then search through their translations. Bug 299423 was recently > put into WTP 3.2 to persist these translations between sessions so that files > that are not edited do not need to be re-translated for each search or refactor > even after closing and opening a workspace. I would be curious if this speeds > up your scenario. As far as I don't see much difference in a time of search between the first launch and the following launchs (even without restart) it seems to me that most part of time is used not for simple indexation but fo smth else. > Not sure what you mean here. I meant that Bug 151689 is still unfixed. Search through JSPs finds nothing after Eclipse restart. > I personally do not see 35-65 seconds completely unreasonable to search through > 12000 JSP files but looking for ways to speed things up is never a bad thing. As I know Apache lucene is used for searching and indexation. That's why I don't understand why does search take so long and why there is a linear dependence of time and quantity of files for search. > There were some fixes that went into the refactoring in November (Bug 164263) > though I don't know if that fix would help with the performance. > What version of WTP are you running on? Last time I've tested on Eclipse 3.6 J2EE M5 (Build ID 20100204-0846), WTP 3.2 (Build ID 20100129044005). I didn't notice any improvements for me. > So just to clarify, the you would like the focus of this bug to speed up the > time it takes for Java refactoring using the JSP participants compared to Java > refactoring without them? Yes. It'll be the best result for me.
I'm using WTP Version: 3.2.2.v201008100100 and Java Search is virtually stuck after finding the results in the sources. Switching off JSP search in Preferences->Web->JSP does not work, using a working set in the "Java Search" dialog doesn't work either. Please help. How can I switch off JSP search in Java search?
(In reply to comment #9) > I'm using WTP Version: 3.2.2.v201008100100 and Java Search is virtually stuck > after finding the results in the sources. > > Switching off JSP search in Preferences->Web->JSP does not work, using a > working set in the "Java Search" dialog doesn't work either. > > Please help. How can I switch off JSP search in Java search? There is an issue if the "Preferences->Web->JSP Files->Include JSP matches in Java searches" is not working. Please include more details in a separate bug report and report that new bug number back here. Thank you.
