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 21294 - [perf] Compile (especailly Clean) on treefs is terribly slow
Summary: [perf] Compile (especailly Clean) on treefs is terribly slow
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: rmatous
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2002-03-07 11:20 UTC by Jaroslav Tulach
Modified: 2008-12-22 18:45 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Few stack traces... (9.85 KB, text/plain)
2002-03-07 11:22 UTC, Jaroslav Tulach 		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 Jaroslav Tulach 2002-03-07 11:20:32 UTC 
I have found a problem in filesystem implementation. It scales from MultiFS to
JavaFS, so it is up to you to find out what is the actual problem. To reproduce
my observation:

1. mount nb_all using JavaCVS (all modules)
2. mount a treefs at openide/src
3. be sure that all sources in openide/src are compiled

Select org/openide and invoke Clean. The action will take for ages
Comment 1 Jaroslav Tulach 2002-03-07 11:22:10 UTC 
Created attachment 4979 [details]
Few stack traces...
Comment 2 _ ttran 2002-03-07 11:49:48 UTC 
added PERFORMANCE keyword
Comment 3 rmatous 2002-03-19 17:29:08 UTC 
You are right, it`s almost unusable. The problem is obvious. First
JavaCvsFileSystem$ListImpl.children is really slow. Second and
probably more serious is that such slow children are invoked from
MFS.updateAll again and again (after delete - from its parent whole
hieararchy down is refreshed). Delete of every file takes few seconds.
Perhaps it`s not necessary to refresh whole hierarchy after delete
deep down in case that FileEvent.getFile ().isData () (the same for
fileDataCreated). Also refreshFolder where map == null (not known
children yet) should not bring in life new FileObjects if not
necessary, then the number of refreshed FileObjects should not grow as
rapidly as it grows at the moment.
Comment 4 rmatous 2002-03-21 16:25:51 UTC 
Fixed in trunk (MultiFileObject.java 1.94).
There is not necessary to update whole hierarchy down if deleted
FileObject is not folder. Now is much better. (Also in updateAll is
not necessary to refresh delegates - will be done with #20528)
Comment 5 Jan Zajicek 2002-03-25 11:01:26 UTC 
verified - dev3.4 build #20020325
Comment 6 Quality Engineering 2003-07-01 16:11:28 UTC 
Resolved for 3.4.x or earlier, no new info since then -> closing.