This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 39213 - Delete action on a large directory takes very long time and the IDE is frozen
Summary: Delete action on a large directory takes very long time and the IDE is frozen
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: rmatous
URL:
Keywords: PERFORMANCE
: 37848 39748 (view as bug list)
Depends on: 39640 39981
Blocks:
  Show dependency tree
 
Reported: 2004-01-26 12:09 UTC by Antonin Nebuzelsky
Modified: 2008-12-22 18:57 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
output form OptimizeIt (95.33 KB, text/html)
2004-02-11 16:53 UTC, rmatous 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Antonin Nebuzelsky 2004-01-26 12:09:46 UTC 
If you select a directory in Explorer and the
directory contains a large amount of
subdirectories and files, DELETE action (after
confirmed) takes very long time and the IDE is
frozen in the meantime.

1. the action should be made faster, it can take
several minutes now while outside the IDE user can
do the delete within several seconds

A simple test shows that on my machine with RH9 a
1000 files are deleted by rm command in 25ms, and
the IDE is deleting the same files for 15 seconds.

2. if we consider this action blocking, a dialog
box with a progress bar must be displayed,
otherwise the IDE should not freeze and the user
should be able to continue working with the IDE
Comment 1 rmatous 2004-01-26 15:01:03 UTC 
This problem has two parts:
1/ FS and DS impl. of delete - too dangerous  (3.6)
2/ impl. of action, showing progress bar and so on - after UI freeze (3.6)


Not trivial. Definitely not part of 3.6.
Comment 2 Marian Mirilovic 2004-02-09 16:02:52 UTC 
*** Issue 39748 has been marked as a duplicate of this issue. ***
Comment 3 Antonin Nebuzelsky 2004-02-11 13:40:43 UTC 
Final solution making the action as fast as the operating system's
native delete may be postponed after 3.6, but performance test results
show there is a regression in directory delete action in comparison to
NB351. The absolute times together with the percentages of comparison
to NB351:

Delete folder with 100 java files (1st invocation)
linux:    3 024 ms (+44.9%)
solaris:  4 574 ms (+47.6%)
xp:       2 531 ms (+49.1%)

Delete folder with 100 java files (2nd and next invocations)
linux:    3 032 ms (+49.0%)
solaris:  4 597 ms (+45.6%)
xp:       2 627 ms (+61.2%)

So, please, investigate this regression.
Comment 4 rmatous 2004-02-11 16:53:00 UTC 
Created attachment 13376 [details]
output form OptimizeIt
Comment 5 rmatous 2004-02-11 17:02:41 UTC 
Seems that ShadowChangeAdapter and its impl. of OperationListener
could be source of regression. 

Jarda volunteered to look at it. Then separated issue will be #39981
was filled.
Comment 6 Antonin Nebuzelsky 2004-02-16 13:43:18 UTC 
Downgrading to P3. This is no longer a regression against NB351.
Actuallly Yarda's fix of 39981 caused the delete action be quite
faster than on NB351. :)
Comment 7 Jaroslav Tulach 2004-02-17 11:47:41 UTC 
Fixed as part of issue 39640.
Comment 8 Antonin Nebuzelsky 2004-02-19 14:36:13 UTC 
Verified with the latest trunk build.
Comment 9 Jaroslav Tulach 2004-08-25 17:25:45 UTC 
*** Issue 37848 has been marked as a duplicate of this issue. ***