It is arguable that it is slow enough to make changes in 6.8...

Created attachment 97797 [details]
experimental script

I made experiment.
- executable is a part of configure script that has intensive file operation
- remote host is a local computer added as remote.
Results:
- local scrip execution time is 15 seconds.
- remote scrip execution time is 53 seconds.
- remote scrip execution time is 49 seconds with disabled pre_open and post_open functions in rfs_preload.
So experiment shows:
- main part of rfs overhead is loading preload library (and possible redirecting open operation)

could you run "collect" to profile this script as if it is executed in remote configuration. Alternatively you can DLight it and figure out how useful DLight is for this kind of troubleshooting.

> main part of rfs overhead is loading preload library 
> (and possible redirecting open operation)

I would say that this is correct for this particular case.

Alexander's experiment 3-4 times delay. But when I measured mysql, it was less then 2 times slower, than on the same (remote) machine without RFS; and this included communication between all parties, uploading files to remote machine, etc.

What I wanted to say by this is:
let's not try optimizing a particular case, 
unless we understand very well that this is the case we really want to optimize.

I would propose to select something (probably all) from the following list:
1) building CLucene (a small project)
2) building MySQL (a medium-size project)
3) running configure script (which, as I understand, shows a different picture, and it seems that the slowness is bigger in this case)

(In reply to comment #4)
> could you run "collect" to profile this script as if it is executed in remote
> configuration. Alternatively you can DLight it and figure out how useful DLight
> is for this kind of troubleshooting.
Technologies do not work in this case.

(In reply to comment #6)
> I would propose to select something (probably all) from the following list:
> 1) building CLucene (a small project)
Another experiment.
- executable is a clan&build of CLucene project.
- remote host is a local computer added as remote.
Results:
- local clan&build time is 62 seconds.
- remote clan&build time is 95 seconds.
- remote clan&build time is 85 seconds with disabled pre_open and post_open functions in rfs_preload.
So, again, experiment shows:
- main part of rfs overhead is loading preload library (and possible redirecting open operation)

Technology limitation.

Created attachment 97842 [details]
Comparation of system calls for local and remote

Test case is:

#!/bin/bash
echo "QQ" > tmp.txt
for (( i = 0; i < 10000; i++))
do
cat tmp.txt tmp.txt tmp.txt tmp.txt tmp.txt tmp.txt tmp.txt tmp.txt tmp.txt tmp.txt > /dev/null
done

Lack of column names make this attachment very cryptic. Usage of .ods makes it even less useful.

Attached table is result of dtrarace:
 dtrace -s ./syscall.d
where script is:
-------------------------
syscall:::entry
/pid == $target/
{
        @[probefunc] = count();
}
-------------------------

Table show that RFS has overhead in system calls (about 2.5M additional system calls).
Obvious improvements:
- getcwd can be reduced if you override resolvepath and cache cwd.
- remove xstat
- reduce in 4 times send and recv

Other improvements is:
- reduce size of binaries by removing duplicated static functions.

Created attachment 97849 [details]
eliminate duplicated static functions and reduce number of getcwd

Created attachment 97852 [details]
Comparation of system calls for local and remote in html format

Created attachment 97866 [details]
Sorry, rigth patch

Integrated into 'main-golden', will be available in build *201004240200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/4fa2024bb51a
User: Vladimir Kvashin <vkvashin@netbeans.org>
Log: Minor changes proposed by Alexander Simon -  #173293 -  Smart Secure Copy is too slow

Just FYI. Recently I measured building MySQL and found that the slowdown is less than I reported in the issue description. I build MySQL locally and remotely on the same Solaris-x86 4-core machine. Both local and remote build resided on this machine local disk. Both remote and local build were launched two times. Results are:

Local: 8:48, 08:19
Remote: 09:02, 09:15

For running configure script, locally and remotely, results are:
Local:   1:15, 1:09
Remote:  1:28, 1:28

I'd like to note that the slowdown depends on the mix of command that are run on remote machine and can also depend on the size of the project.

please evaluate for release 7.0, should anything else be done?

Is it done, or further improvement is needed?

My feeling is that it's OK now; but I have to measure.

I can suggest improvement:
- use release flags, strip dwarf.
It allows to decrease size of preloaded library. Now library size 70K.

I haven't completed comprehensive measurements, here are some results. 

Project: MySQL 5.1.38

Machines: server (elif) and workstation (my personal one), 
both running Solaris-x86

Variants:

1. Local/terminal
	Sources reside on the server local disk
	Build is launched from a terminal (KDE Konsole) on the server
2. Local/IDE
	Sources reside on a server local disk
	IDE runs on the server
	Build is launched from IDE
3. Remote/IDE	
	Sources reside on workstation local disk 
	IDE runs on workstation
	Build is launched on the server with local user, i.e. remote mirror resides on the server local disk
	
Data (some measurements run twice or several times)

Configure:
Local/terminal 01:28
Local/terminal 01:20
Local/IDE      01:06
Remote/IDE     02:09

Build:
Local/terminal 09:46
Local/terminal 08:21
Local/IDE      05:40
Local/IDE      04:44
Remote/IDE     10:27 (1-st time)
Remote/IDE     09:10 (2-nd time)
Remote/IDE     09:16 (3-th time)

*** Bug 223088 has been marked as a duplicate of this bug. ***

Not in this release