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 233710 - [Go to file] Allow inaccurate results if the search is slow
Summary: [Go to file] Allow inaccurate results if the search is slow
Status: RESOLVED WONTFIX
Alias: None
Product: utilities
Classification: Unclassified
Component: Jump To (show other bugs)
Version: 7.4
Hardware: PC Linux
: P3 normal (vote)
Assignee: Tomas Zezula
URL:
Keywords:
: 235208 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-07-31 11:30 UTC by tomzi
Modified: 2014-08-01 12:05 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
IDE log (715.07 KB, text/plain)
2013-07-31 11:30 UTC, tomzi
Details
Goto file selfsampler started before opening the dialoge (4.78 MB, application/x-netbeans-profiler-npss)
2013-07-31 11:31 UTC, tomzi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tomzi 2013-07-31 11:30:02 UTC
.) I opened my tiles-defs.xml
.) copied a jsp filename eg 'myjsp.jsp'
.) pressed SHIFT-CTRL-R (eclipse mapping) to open the 'Goto File' dialoge.
.) the dialoge opens with the filename prefilled, but search is not starting yet, because of some other NB bug, so I delete the last letter and enter it again to make it start searching.

... but it never finds it although the 'Prefer current project is checked' after 5minutes I give up.


Product Version = NetBeans IDE 7.4 Beta (Build 201307092200)
Operating System = Linux version 3.8.0-26-generic running on amd64
Java; VM; Vendor = 1.7.0_25
Runtime = Java HotSpot(TM) 64-Bit Server VM 23.25-b01
Comment 1 tomzi 2013-07-31 11:30:08 UTC
Created attachment 138058 [details]
IDE log
Comment 2 tomzi 2013-07-31 11:31:30 UTC
Created attachment 138059 [details]
Goto file selfsampler started before opening the dialoge
Comment 3 Dusan Balek 2013-07-31 13:49:29 UTC
FileSearchAction waits for the extremely slow Maven project queries (SharabilityQuery and FileOwnerQuery) as can be seen from the attached snapshot. Reassigning to Maven.
Comment 4 Milos Kleint 2013-08-21 07:32:12 UTC
at least 5 MavenProject instances get loading during SharabilityQuery. That would indicate that child project's files were touched and the child project (project in subfolder) was no opened. It could be either 5 distinct projects or also just one and with low heap memory, it's SoftReference to MavenProject would get cleared immediately and reloaded subsequently.

IMHO nothing can be done on maven side of things as these are only fed data by those calling them and for the data entered here, the response is slow.
Comment 5 tomzi 2013-08-21 09:43:58 UTC
5 minutes slow?
To build the whole project takes less time....

It would be more satisfying to have inaccurate results that having no results at all for a very long time....
Comment 6 Tomas Zezula 2013-08-21 15:41:48 UTC
Unfortunately jump to cannot help. It has to behave consistently with all the other IDE features and has to use default search filters API. Looking at the snapshot nearly all the time is spent in DelegatingSearchFilter.traverseFolder which loads the Maven projects. As Maven support cannot fix this problem it's probably unfixable. The actual search of files is less then second the rest is spent in DelegatingSearchFilter.traverseFolder -> Maven.
Comment 7 Jaroslav Havlin 2013-08-21 16:52:00 UTC
(In reply to Tomas Zezula from comment #6)
> Looking at the snapshot nearly all the time is spent in
> DelegatingSearchFilter.traverseFolder which loads the Maven projects.
> As Maven support cannot fix this problem it's probably unfixable.
Yes, probably unfixable.

(In reply to tomzi from comment #5)
> It would be more satisfying to have inaccurate results that having no
> results at all for a very long time....
Maybe some option for "Fast but Inaccurate" search cold be added to the "Go to File" dialog.
Something similar to "Search in Generated Sources" in "Find in Projects" dialog,
which disables the SharabilityQuery (in that case the reason is not performance, but results).
But I'm not really convinced that it's worth implementing.

(A very weak "workaround" would be to use Find in Projects instead,
with enabled option "Search in Generated Sources".)
Comment 8 tomzi 2013-08-22 07:37:18 UTC
Why not 

1.) do a 'inaccurate' Search with the index that is currently available, which should be blazing fast, 
2.) but in the background the accurate version still continues showing a progressbar or sth.

The most frustrating part is, that keeps showing the 'Search is in Progress' message, but you don't really know what the problem is.

I do understand that the index needs to be updated at some time, but I bet that in 99% of the cases the file that I search for has NOT been changed, thus a immediate reponse would be prefereble.

Another thing - you say it took a really long time in loading the maven project in DelegatingSearchFilter.traverseFolder but I really do not recall that the Projects where still 'opening'. I usually wait after a restart that everything finished loading.
Comment 9 tomzi 2013-08-22 07:41:29 UTC
BTW 'unfixable' - really?! Usually there is a way, it's just not obvious right now :)
Comment 10 Tomas Zezula 2013-08-22 08:08:09 UTC
>1.) do a 'inaccurate' Search with the index that is currently available, which >should be blazing fast, 
The search using index is accurate, however before it starts the index first needs to get source folders which should be searched and this took the time.

>I do understand that the index needs to be updated at some time, but I bet that >in 99% of the cases the file that I search for has NOT been changed, thus a >immediate reponse would be prefereble.
The index never updates in query, the index is updated in background when project is indexed. So the index just do the query. However before it does the query it needs to ask the project which folders should be queried.


>BTW 'unfixable' - really?! Usually there is a way, it's just not obvious right now :)
It was conditionally unfixable ;-)
If 98% of the time is spent in project queries, the rest in FileSearchAction making these 2% in FileSearchAction faster makes no sense. The unfixable depends on Maven, if it resolves these 98% or not.

There is a "workaround" which I can use not to use the default search filters however this will cause that even build folders are searched which will be a regression.
Comment 11 tomzi 2013-08-22 10:25:02 UTC
So how can it be then, when the maven projects already opened, meaning all infos are read into netbeans that a 'simple' project query takes minutes to complete?
Comment 12 tomzi 2013-08-22 10:31:59 UTC
If for whatever the project query just could take a long time (eg. totally madeup example, the project is stored on superslow network drives) wouldn't it make sense to always

1) search with inaccurate (old) project infos first 
2) at the same time update the project infos and merge the search results with (1)

and display the result.
Comment 13 Tomas Zezula 2013-08-22 10:40:55 UTC
There is nothing like "old" info.
The search can just asks Maven about shareability of source root whatever it returns.
As mkleint explained in the comment #4 the Maven holds the info as SoftRef and loads it when needed. There is either actual info or nothing.
So the merging is nonsense here.
Comment 14 tomzi 2013-08-22 11:30:27 UTC
OK - I guess I really don't get the problem here. But I don't have to. I just wanted to report that NB is ridiculously slow in some cases and it does not give any hint to the user why, which is frustrating.

The only other thing I did want to suggest to 'somehow' defer looooooonglasting queries in a devide and merge fashion to actually see results, since obviously NB does get stuck somewhere. And if it is possible to at least search part of the list of projects, say 10 out of 15 projects return results immediately and 5 take a lot longer because of heap problem or other reasons. But you still see results of the 10 projects first....

Anyway you know the details.
Comment 15 Dusan Balek 2013-08-29 08:14:38 UTC
*** Bug 235208 has been marked as a duplicate of this bug. ***
Comment 16 Tomas Zezula 2014-08-01 12:05:14 UTC
The Go To File is now asynchronous and displays partial results.