Prevent Eclipse from IO access to source code on *any* GUI interaction

[Marcel Müller]

Hi,

I am working with Eclipse Juno in a cross platform development. The
source code is on a NFS server, which is not that fast.
Unfortunately Eclipse seems to access the source files over and over, I
guess to verify whether they are modified or removed in the file system.
This causes GUI interactions like moving files from one editor to
another to become incredibly slow. It sometimes takes seconds until the
green highlight responds to mouse movements. And often I create new
editors accidentally. Other actions like changing the current file are
affected too.

Is it possible to avoid these kind of access? I do not need the up to
date checks. Especially not /that/ often.

Using a local workspace speed up the things at least by a factor 10. But
this also increases the compile time on the remote machine by a factor
10, which is definitely undesirable.


Marcel

 

[Lew]

I am working with Eclipse Juno in a cross platform development. The
source code is on a NFS server, which is not that fast.
Unfortunately Eclipse seems to access the source files over and over, I
guess to verify whether they are modified or removed in the file system.
This causes GUI interactions like moving files from one editor to
another to become incredibly slow. It sometimes takes seconds until the
green highlight responds to mouse movements. And often I create new
editors accidentally. Other actions like changing the current file are
affected too.

Is it possible to avoid these kind of access? I do not need the up to
date checks. Especially not /that/ often.

Using a local workspace speed up the things at least by a factor 10. But
this also increases the compile time on the remote machine by a factor
10, which is definitely undesirable.

Wha...?

How does using a local workspace affect remote builds?

Put a git source-code repository (e.g., git) on the remote, clone it to your local machine and do your
development locally, then push the changes to the remote repository and do the official builds there.

 

[Arne Vajhøj]

I am working with Eclipse Juno in a cross platform development. The
source code is on a NFS server, which is not that fast.
Unfortunately Eclipse seems to access the source files over and over, I
guess to verify whether they are modified or removed in the file system.
This causes GUI interactions like moving files from one editor to
another to become incredibly slow. It sometimes takes seconds until the
green highlight responds to mouse movements. And often I create new
editors accidentally. Other actions like changing the current file are
affected too.

Is it possible to avoid these kind of access? I do not need the up to
date checks. Especially not /that/ often.

Using a local workspace speed up the things at least by a factor 10. But
this also increases the compile time on the remote machine by a factor
10, which is definitely undesirable.

If I have understood you correct then:

Eclipse--(NFS remote)--workspace files--(local)--build

is slow for Eclipse and:

Eclipse--(local)--workspace files--(NFS remote)--build

is slow for the build.

I think you will be much more happy with:

Eclipse--(commit)--VCS repo--(update)--build
| |
(local) (local)
| |
workspace files files

Arne

 

[Nigel Wade]

Hi,

I am working with Eclipse Juno in a cross platform development. The
source code is on a NFS server, which is not that fast.
Unfortunately Eclipse seems to access the source files over and over, I
guess to verify whether they are modified or removed in the file system.
This causes GUI interactions like moving files from one editor to
another to become incredibly slow. It sometimes takes seconds until the
green highlight responds to mouse movements. And often I create new
editors accidentally. Other actions like changing the current file are
affected too.

Is it possible to avoid these kind of access? I do not need the up to
date checks. Especially not /that/ often.

Using a local workspace speed up the things at least by a factor 10. But
this also increases the compile time on the remote machine by a factor
10, which is definitely undesirable.


Marcel

I fully understand the problem, it's just the same with NetBeans. I find
it unworkable to have project source on an NFS server.

I would recommend that you install sub-version, or some other version
control system on the NFS server. Choose one which is well supported in
Eclipse. I don't use use Eclipes so can't recommend the best choice. I
use the SVN plugin in NetBeans, which allows me to work from home just
as easily as from my desktop at work.

Keep the repository on the central server. Check out a working copy
which is then local to your IDE. Perform regular check-in/commit as
appropriate. You can then build anywhere you wish, just check out/update
the latest copy on the build system (or any other previous revision) and
build it. You also get added the benefit of full revision control, which
is something I'd recommend for anyone.

 

[William Bonawentura]

I am working with Eclipse Juno in a cross platform development. The source code is on a NFS server, which is not that fast.

I was bought SSD disc for Eclipse Workspace.

 

[Robert Klemme]

I am working with Eclipse Juno in a cross platform development. The
source code is on a NFS server, which is not that fast.

NFS has also other issues (file locking, timestamps - might be dependent
on the NFS version used) which make it a sub optimal choice for
development and building in my experience.

Unfortunately Eclipse seems to access the source files over and over, I
guess to verify whether they are modified or removed in the file system.
This causes GUI interactions like moving files from one editor to
another to become incredibly slow. It sometimes takes seconds until the
green highlight responds to mouse movements. And often I create new
editors accidentally. Other actions like changing the current file are
affected too.

Is it possible to avoid these kind of access? I do not need the up to
date checks. Especially not /that/ often.

You can tweak that a bit via settings but I am afraid not to a level
which would make working on an NFS share comfortable.

Using a local workspace speed up the things at least by a factor 10. But
this also increases the compile time on the remote machine by a factor
10, which is definitely undesirable.

That I don't really understand. Wouldn't you check out your files on
the remote machine from some kind of version control system and build
there? You're not placing only build artifacts on the NFS mount, do you?

If you do not want to go down the route of distributed version control
(which you should for a whole lot of other reasons) you could have your
workspace local and rsync it when doing the build to the remote machine.
Then start the build there. But this is really a crutch.

Kind regards

robert

 

[Arne Vajhøj]

I was bought SSD disc for Eclipse Workspace.

It is probably nice but it is not necessary.

Arne