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.
|Summary:||Background scanning makes cut/copy and paste of files really slow|
|Component:||Data Systems||Assignee:||Jaroslav Havlin <jhavlin>|
|Severity:||normal||CC:||issues, JPESKA, jtulach, mmirilovic, saubrecht, tzezula, uireviews, VesaPa|
|Issue Type:||DEFECT||Exception Reporter:|
|Bug Depends on:||225012|
The suspend and cancel buttons on a progress in KDE4
Initial sketch of resumable handle
Description javydreamercsw 2012-10-07 17:49:57 UTC
Product Version = NetBeans IDE Dev (Build 201210050002) Operating System = Windows 7 version 6.1 running on x86 Java; VM; Vendor = 1.7.0_07 Runtime = Java HotSpot(TM) Client VM 23.3-b01 Isn't there a way to disable it during this kind of operations? In slower computers it can get ridiculous.
Comment 2 Tomas Zezula 2012-10-17 14:06:36 UTC
There is an interceptor which suspends scan. It's used by the editor code completion, navigator, Go to type, etc. They suspend the scan when they are running. Other actions can be added, the copy paste, cut paste sounds reasonable to me.
Comment 3 Tomas Zezula 2012-10-22 09:59:26 UTC
The parsing.api has an API to suspend & resume scan. The platform (datasystem) needs to call it in copy, rename ops. From discussion with Jarda the progress.api seems to be good candidate to give user a chance to suspend the task.
Comment 4 Jaroslav Tulach 2012-10-23 11:59:12 UTC
Rather then doing some heuristics to find out what should and should not take precedence, we can implement additional suspend feature for certain progress tasks. Then the user can control which of multiple suspendable tasks should finish sooner. (probably we don't want the user to suspend anything, if there is a single suspendable task running, as we would like to finish tasks like background scanning one day)
Comment 5 Jaroslav Tulach 2012-10-23 12:02:39 UTC
Created attachment 126390 [details] The suspend and cancel buttons on a progress in KDE4
Comment 6 uireviews 2012-11-13 13:08:21 UTC
Which features depending on the suspended task will not be functional until the user resumes the task and it finishes? Will this be indicated anyhow by the affected features?
Comment 7 Petr Somol 2012-12-10 13:21:36 UTC
(In reply to comment #6) > Which features depending on the suspended task will not be functional until the > user resumes the task and it finishes? Will this be indicated anyhow by the > affected features? among others the following essential functionality does not fully work until scanning has finished: code completion, navigation (go to type, go to declaration, etc), hints, find usages. Since 7.2 NB allows users to work with editor while scanning is still in process, however the related functionality is restricted or based on outdated (cached) info. E.g., when code completion is not yet available, it is indicated in the completion pop-up. Find usages with unfinished scan produces an incomplete (and often quite short) list of occurrences and a warning that it should be re-run after the scan has finished. Navigation just does not work; Ctrl-click on type name does nothing. Etc. IMHO permitting to suspend a scan can lead to lots of confusion among general users. If permitted, it would certainly be a feature for power users only, as it would require strict attention and very good knowledge of why and when to apply it.
Comment 8 Jan Peska 2012-12-12 13:46:06 UTC
After offline discussion with Jarda here is a clarification of scenarios when the suspension mechanism would be used. 1) User is copying/cutting and pasting e.g. large amount of files which takes a long time to perform by itself. If the background scanning is in progress the copying is significantly slower. Proposed solution: Show the copying in the Progress bar and enable suspend action for BOTH Background scanning and copying. With this functionality a user can decide e.g. that copying should be performed first so she suspends scanning, lets copying to be completed and then resume scanning manually. 2) This scenario is probably more obvious since the most of us (NB developers) encounter it very often. User wants to build some project externally (as we do in NetBeans) and she wants to suspend background scanning because it slows building significantly. Since some of these details were not so obvious from the issue description I suggest to discuss it again on UI steering meeting taking this new information into account.
Comment 9 Jan Peska 2013-01-17 10:05:30 UTC
After UI team meeting and discussion with Jarda we've decided that this scenario is not a proper reason for introducing suspend functionality for Progress API, but the functionality itself can be useful for other scenarios. So I've reported new enhancement (issue #225012) in which we can discuss other relevant usages of it and I'm reassigning this particular issue back to Jarda.
Comment 10 Jaroslav Tulach 2013-01-17 14:55:07 UTC
Well, this is more a request for the parsing API. The parsing makes something else slow! Not the opposite way. I have separate request to provide progress for copy/paste reported as enhancement 204570.
Comment 11 Tomas Zezula 2013-08-07 13:37:37 UTC
>Well, this is more a request for the parsing API. The parsing makes something >else slow! Not the opposite way. I've thought that the API | SPI should be defined by the lower layer. However if you think that the PasteAction should depend on the Parsing API you can already suspend scan by: Lookup.getDefault().lookup(ScanSuspendImplementation.class).suspend()
Comment 12 VesaPa 2013-08-28 15:08:54 UTC
I'm troubled by the slowness of scanning with NetBeans 7.4 Beta. Is it correct that "Background scanning of projects" happens disturbingly every now and then even if "Enable auto-scanning of sources" has been disabled? And even when I'm compiling a project, it seems that the scanning operation is competing with the compile operation.
Comment 13 VesaPa 2013-08-28 15:10:05 UTC
I'm troubled by the slowness of scanning with NetBeans 7.4 Beta. Is it correct that "Background scanning of projects" happens disturbingly every now and then even if "Enable auto-scanning of sources" has been disabled? And even when I'm compiling a project, it seems that the scanning operation is competing with the compile operation. So I'm voting for faster performance and less cluttering automation.
Comment 14 Tomas Zezula 2013-08-29 13:22:35 UTC
>Is it correct that "Background scanning of projects" happens disturbingly every >now and then even if "Enable auto-scanning of sources" has been disabled? The Enable auto-scanning of sources just turns off the "Checking for modified files". It disables check of file modifications for which there is no fast native push change detection (inotify, FSEventChannel). Such a changes are detected using file system crawling mostly when the IDE gets focus. The background scan updates caches when there is a change in source root(s). Without this metadata update the changed (added) files and their content (classes, methods, etc) will not be visible for the IDE (they will not be available in Go To Type, Go To File File, Find Usages, Go to Declaration, Code Completion, in case of Java Compile On Save even in Project Run). Regarding the concurrent run of paste and scan I agree that these actions should not run in parallel. There are several such actions like navigation, refactoring, code completion which already suspend the scan. The only thing needed is that the paste action suspends the scan until the paste is done.
Comment 15 Jaroslav Tulach 2013-12-20 08:39:13 UTC
Created attachment 143358 [details] Initial sketch of resumable handle
Comment 16 Jaroslav Tulach 2014-12-11 10:56:47 UTC
Resetting to default module owner. I still believe "suspend" of various background tasks is the only solution to the problem, but I am not going to push it forward myself.