Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #21168 > unrolled thread

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

Back to article view | Back to comp.lang.java.programmer

Contents

  Prevent Eclipse from IO access to source code on *any* GUI interaction Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-01-07 22:15 +0100
    Re: Prevent Eclipse from IO access to source code on *any* GUI interaction Lew <lewbloch@gmail.com> - 2013-01-07 16:02 -0800
    Re: Prevent Eclipse from IO access to source code on *any* GUI interaction Arne Vajhøj <arne@vajhoej.dk> - 2013-01-07 19:16 -0500
    Re: Prevent Eclipse from IO access to source code on *any* GUI interaction Nigel Wade <nmw@ion.le.ac.uk> - 2013-01-08 09:37 +0000
    Re: Prevent Eclipse from IO access to source code on *any* GUI interaction "William Bonawentura" <nie@ma.mnie.pl> - 2013-01-08 15:03 +0100
      Re: Prevent Eclipse from IO access to source code on *any* GUI interaction Arne Vajhøj <arne@vajhoej.dk> - 2013-01-08 19:55 -0500
    Re: Prevent Eclipse from IO access to source code on *any* GUI interaction Robert Klemme <shortcutter@googlemail.com> - 2013-01-08 23:30 +0100
      Re: Prevent Eclipse from IO access to source code on *any* GUI interaction Martin Gregorie <martin@address-in-sig.invalid> - 2013-01-08 22:56 +0000

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

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

[toc] | [next] | [standalone]

#21174

Marcel Müller wrote:
> 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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#21176

On 1/7/2013 4:15 PM, Marcel Müller wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#21205

On 07/01/13 21:15, Marcel Müller wrote:
> 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.

-- 
Nigel Wade

[toc] | [prev] | [next] | [standalone]

#21209

> 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.

[toc] | [prev] | [next] | [standalone]

#21232

On 1/8/2013 9:03 AM, William Bonawentura wrote:
>> 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.

It is probably nice but it is not necessary.

Arne

[toc] | [prev] | [next] | [standalone]

#21224

On 07.01.2013 22:15, Marcel Müller wrote:

> 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


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#21225

On Tue, 08 Jan 2013 23:30:47 +0100, Robert Klemme wrote:

> 
> 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?
>
The OP did say something about cross-compiling though, as he didn't say 
anything about native code, I don't know how that affects things.

In general, I'm with you: why can't he use version control to keep the 
local copy of the code an sync with the central repository?

If there's some reason why that can't be done, since IIRC he's running 
*NIX on both local and remote boxes and (presumably) using ssh for remote 
access, the OP can equally well do everything on the central system. All 
he needs to run the IDE remotely is to enable X11 forwarding for ssh. 



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web