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: | Interactive IDE actions like code completion, navigation slowed down by VCS | ||
|---|---|---|---|
| Product: | versioncontrol | Reporter: | Tomas Zezula <tzezula> |
| Component: | Mercurial | Assignee: | Ondrej Vrabec <ovrabec> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | jtulach |
| Priority: | P3 | Keywords: | PERFORMANCE |
| Version: | 6.x | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 171183 | ||
| Attachments: | Snapshot | ||
Please run with -J-Dorg.netbeans.modules.mercurial.status.level=500, we'll get at least more info from logs (what files it is scanning, how long it takes, etc.) OK, I will run the IDE with logging enabled. How long it takes is visible from the attached snapshot. > How long it takes is visible from the attached snapshot.
It probably took longer than that, hg status must have already been running at the time Go to Type started scanning. I doubt it was triggered at the same moment.
Yes, it took at least this time. It's not a problem that it runs for long time but the problem is the IO contention. When user invokes code completion or something he is hardly interested in hg status he want the code completion as he invokes it. There should be something like fs's priorityIO which gives lower priority to background IO where there is a request for interactive IO. But I agree that in case of hg it's not so easy as in case of fs as it forks external process. I think that it's just the case, that when there is not an API in Netbeans to support some activity, that you'll never be able to control it, realistically. The owners of the Mercurial plugin, and other VCS users, really need to understand how much of a problem, endless disk scanning is. If the user hasn't requested something like that, it seems like a poor choice to "turn it on", or "start it in the background", if it can't be controlled and managed to have limited impact on the IDE/computer system. There are now new APIs in Java for directory scanning that don't load huge quantity of String file names into memory (String[] File.list()). So, it would seem that many things like "scanning directory trees" could be made into a netbeans API with a callback mechanism which returns results, and thus allows the IDE to put the scanning into a separate thread that is managed in a way that can minimize disk contention as well as internal netbeans resource locking. |
Created attachment 98991 [details] Snapshot Several priority IDE actions like code completion, navigation are slowed down by VCS (IO contention). See attached snapshot.