Bugzilla – Full Text Bug Listing
| Summary: | Remote indexing via RDT is about 3X slower than indexing locally-located code | ||
|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Corey Ashford <cjashfor> |
| Component: | Remote Tools | Assignee: | Project Inbox <ptp-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | mikekucera, recoskie, rsjoao, wainersm |
| Version: | 5.0.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux-GTK | ||
| Whiteboard: | |||
|
Description
Corey Ashford
In general, remote indexing is typically on par with local indexing, performance wise. Depending on the speed of the machines involved, it's often faster in the remote case, as usually your remote server has more horsepower than your desktop. I'm not sure what's going on in your setup. Now that our product work is winding down one of us will have more time to get together with you and do some work to debug this. I tried to create a simple helloWorld project on a remote server and could also verify a longer amount of time during indexing compared to indexing a local one. Steps to Reproduce: 1. Create an empty Remote C/C++ project using Remote Tools. 2. Create a new empty main.c file and type in 'hello world' source code. 3. Build the project. 4. Measure time for indexing. Also noticed the longer time it took to re-open a project Steps to Reproduce: 1. Close the current remote project 2. Re-open the remote project 3. Measure the time to index the project. *Note I have a ping response time=59.6 ms to the remote server and 0% packet loss Creating a project or opening a closed one will take longer, there is no way around that. Those do remote file access, and that's going to be slower on a remote system than your local one. Remote indexing should have a small delta slowdown, but shouldn't be very much, all things being equal. Remote indexing sends a request to the server, which does the indexing; there is no remote file access in this case. All that is sent pack is progress reporting updates, which are fairly small. If there are unresolved inclusions those errors are sent back at the end of the operation. The first time you do an index-related operation during a given connection session, it will send a list of all the files in your project to the server. That might take some time if you project is really huge. I assume you're using a regular remote project and not a synchronized one. That one tries to index locally with remote headers... probably going to be very slow. Another thing to keep in mind is where are your home directories? By default, the indexer places the PDOM files in ~/.eclipse. If your home directory is an NFS share, that can slow things down. You really want the indexing directory (configurable in the service configuration) to be a directory local to the server. To be clear, I am using the standard Remote C/C++ project, not a synchronized project. My workspace and home directory are on my laptop's hard drive. There are no NFS-mounted directories on either the remote host machine nor on the client machine. (In reply to comment #3) > Remote indexing should have a small delta slowdown, but shouldn't be very much, > all things being equal. Remote indexing sends a request to the server, which > does the indexing; there is no remote file access in this case. All that is > sent pack is progress reporting updates, which are fairly small. If there are > unresolved inclusions those errors are sent back at the end of the operation. If its the same indexer task just running on the server then yes theoretically it should be just as fast. Especially when its on the same physical machine. I have a gut feeling that this has something to do with the progress reporting updates, they might be blocking the remote indexer thread. Looks like RemoteIndexProgressMonitor calls DataStore.refresh(). What does refresh() actually do? The javadocs don't say much. If it blocks until the client and server datastores are in sync then that might be the cause of the problem. (In reply to comment #6) > I have a gut feeling that this has something to do with the progress reporting > updates, they might be blocking the remote indexer thread. Looks like > RemoteIndexProgressMonitor calls DataStore.refresh(). What does refresh() > actually do? The javadocs don't say much. If it blocks until the client and > server datastores are in sync then that might be the cause of the problem. DataStore.refresh() is supposed to sync them, as far as I know. I'm skeptical that's what's wrong though or we'd be seeing this all the time. Corey sees the same behaviour on both local (connected via localhost) and when connecting remotely. After talking with Chris briefly, he said that my CDT may be too far out of date and that some fixes were made to the scanner for the GNU toolchain. I was using CDT 8.0.0 - the official release, and the latest PTP build that's available via the repos, which is from around Sep 1st. I found that I can install the latest nightly build from hudson here: https://hudson.eclipse.org/hudson/job/cdt-nightly/? And so I installed it. With this CDT, the indexing problems seem all to have been fixed. The indexer is now successfully finding the include files, the photran indexer flashes up in the progress view a couple of times, but then completes, and best of all, the indexing time has dropped dramatically. It takes only about 10 minutes to complete a remote indexing operation. I also surfed around the source code, and it does appear that the indexing is actually working, because I can look at call stacks, navigate to definitions of types, etc. So perhaps we can call this "fixed in SR1" ? (In reply to comment #8) > So perhaps we can call this "fixed in SR1" ? I think it's more the case that your CDT and PTP were mismatched, so I'm not sure saying we fixed anything is accurate. In any case, I'm going to close this. Thanks for being patient while we figured it out. *** Bug 356652 has been marked as a duplicate of this bug. *** |