---

I/O Improvements

Lightweight FileObject operations

• Delete of files was incredibly slow in 6.0 (IZ 106128,

IZ 122594) especially in case of deep file hierarchies. The overhead caused by creation of lock file on disk, will be minimized by identifying cases where the lock file is really needed and creating it only in such situations.

• • when there is just one locked file, it does not need lock on disk
  • given the locking system on masterfs, it is only necessary to create file locks if we are locking file named as already locked file, then one needs to create lock files for all files with the same name and verify there are not identical
  • The speedup is about 50%+-20% compared to the poor 6.0 case. In almost all cases delete just deletes and no writes are done anymore.

Number of file object instances

There is already stuff prototyped in the excessive disk usage area and it can also significantly decrease network access. Actually I work on evaluation. See Radek's issue, #123542 for details.

todo:

• Patched security manager for testing,
• native libraries evaluation,
• ...

Additional Measurements

I tried to recursively traverse NetBeans sources on different partitions (clone of NetBeans repository, built up).

HW: Tecra M3.1st measuring is immediately after system boot and login.

OS	1st (s)	2nd (s)	3rd (s)	4th (s)	5th
WinXP (ntfs)	279	19	27	19	20
Ubuntu 7.10 (ext3)	166	4	4	4	4
WinXP (samba)	714	682	N/A	N/A	N/A
Ubuntu 7.10 (nfs)	155	150	163	91	177

ntfs - almost defragmented, partition was almost new.

ext3 - extensively used before

nfs - hs-eprg06-01.czech:/export/home1/pf124312 on /home/pf124312 type nfs (rw,addr=129.157.16.144)

I tried also to measure how single read byte works on both platforms. Reading limewire project byte by byte:

WinXP (ntfs)	76.079	78.875	65.042	61.016	69.562
Ubuntu 7.10	44.719	42.768	42.745	42.867	42.814

The measurement was done immediately when system fully started. What I found interesting, when using system for a while (making different task), I got a better results:

WinXP	53.422	53.046	53.047	53.172	54.438
Ubuntu 7.10	39.617	33.914	33.286	33.480	33.572

Conclusion: The results vary, only the thing I can confirm is slower ntfs filesystem.

Eliminate single byte reads/writes in file input/output streams

We are trying to reduce the number of I/O hits. This effort is tracked in Umbrella issue.

Single byte reads/writes (number of single byte reads/writes):

Start-up	6.0.1	6.1
w/o userdir	1098863	1699
existing userdir	7747	1265

Update tracking files during start-up

We eliminated ~300 update_tracking files read during start-up in autoupdate (they are no longer read and parsed.)

Action	Ubuntu 6.0.1	Ubuntu 6.1 (0317)	WinXP 6.0.1	WinXP 6.1 (0317)
Out Of The Box Startup -- Classes-Loaded	6986	4755	N/A	6691
Scanning Java Project Classpath	34.0s	19.6s	35.4s	20.6s
Expand Source Packages Node [1]	603ms	459ms	1440ms	3996ms (?)
Expand Source Packages Node [2]	37ms	35ms	40ms	34ms
Invoke Code Completion dialog in Editor [1]	1081ms	339ms	1142ms	311ms
Invoke Code Completion dialog in Editor [2]	632ms	29ms	749ms	36ms
Expand folder with 100 java files [1]	1949ms	620ms	2128ms	1202ms
Expand folder with 100 java files [2]	554ms	423ms	285ms	259ms

Network Measurements

Client: Ubuntu Linux Sources: NFS, Solaris 10 Project: limewire, nbextra Actions: src node -- expand project src node, wait until all packages are computed (progress finished) dir node -- expand com.limegroup.gnutella package (>100files, several dirs)

First number in each measurement indicates time immediately after system boot and NetBeans start. Other numbers are measured after NetBeans restart.

Action	NetBeans 6.0.1	NetBeans 6.1 trunk (b1471)
src node [1]	17.4s 17.2s 16.0s	9.1s 9.3s 8.6s
src node [2]	18.3s 16.7s 16.0s	10.1s 9.4s 8.4s
dir node [1]	2.7s 2.5s 2.6s	1.4s 1.5s 1.4s
dir node [2]	2.7s 2.7s 2.5s	1.6s 1.3s 1.3s

(Stopwatch measurements)

Scan scheduled

Projects opening	1st	2nd	3rd	4th	5th
postponed scanning	4697 ms	4661 ms	4760 ms	4983 ms	4716 ms
immediate scanning	7428 ms	6754 ms	7412 ms	6785 ms	7135 ms