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 36643 - PERFORMANCE: Recursive Add&Commit hangs on OOME and problem in RecursiveFolderCommand
Summary: PERFORMANCE: Recursive Add&Commit hangs on OOME and problem in RecursiveFolde...
Status: RESOLVED FIXED
Alias: None
Product: obsolete
Classification: Unclassified
Component: vcsgeneric (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Martin Entlicher
URL:
Keywords: PERFORMANCE
Depends on: 32089
Blocks:
  Show dependency tree
 
Reported: 2003-10-16 14:07 UTC by dmladek
Modified: 2005-04-05 17:01 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
snapshot of Exception (4.43 KB, image/png)
2003-10-16 14:11 UTC, dmladek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dmladek 2003-10-16 14:07:26 UTC
Product Version       = NetBeans IDE Dev (Build
200310160100)
  Operating System      = Linux version
2.4.20-18.9 running on i386
  Java; VM; Vendor      = 1.4.2; Java HotSpot(TM)
Client VM 1.4.2-b28; Sun Microsystems Inc.
  Java Home             =
/usr/local/java/j2sdk1.4.2/jre
  System Locale; Encod. = cs_CZ; ISO-8859-2
  Home Dir; Current Dir = /usr/local/home/delphym;
/usr/local/forte/forte3/NBdev-last/netbeans/bin
  IDE Install; User Dir =
/usr/local/home/delphym/NBdev-last;
/usr/local/home/delphym/.netbeans/dev
----------------------------------------------------

I have simple dir structure:

`-- validation
    |-- CVS
    |-- pakage
    |   |-- CVS
    |   `-- del
    |       |-- CVS
    |       `-- prd
    |           `-- CVS
    |-- pakage1
    |   |-- CVS
    |   `-- del
    |       |-- CVS
    |       `-- prd
    |           `-- CVS
    |-- testdir11201
    |   `-- CVS
    |-- testdir11355
    |   `-- CVS
    |-- testdir13108
    |   `-- CVS
    |-- testdir16873
    |   `-- CVS
    |-- testdir17413
    |   `-- CVS
    |-- testdir18940
    |   `-- CVS
    |-- testdir21201
    |   `-- CVS
    |-- testdir26464
    |   `-- CVS
    |-- testdir27253
    |   `-- CVS
    |-- testdir27542
    |   `-- CVS
    |-- testdir28153
    |   `-- CVS
    |-- testdir3077
    |   `-- CVS
    |-- testdir32315
    |   `-- CVS
    |-- testdir35724
    |   `-- CVS
    |-- testdir37356
    |   `-- CVS
    |-- testdir37858
    |   `-- CVS
    |-- testdir39207
    |   `-- CVS
    |-- testdir39539
    |   `-- CVS
    |-- testdir42238
    |   `-- CVS
    |-- testdir43128
    |   `-- CVS
    |-- testdir45266
    |   `-- CVS
    |-- testdir45990
    |   `-- CVS
    |-- testdir46117
    |   `-- CVS
    |-- testdir46433
    |   `-- CVS
    |-- testdir56494
    |   `-- CVS
    |-- testdir58215
    |   `-- CVS
    |-- testdir60294
    |   `-- CVS
    `-- testdir6338
        `-- CVS

70 directories

In each testdirXXXXXX was testfile.java
So, that's not so huge, isn't it?

But I several times (c.10 times) copied the whole
working into one of the testdirXXXX so, the
hiearchy became 2^n bigger then it used to be:-o

And this whole dir structure I  Add&Commit into
emty local repository.

It took quite long time so I went to lunch:-)
And after my return, the ide was frozen with OOME
and Exception detected in class
org.netbeans.modules.vcs.profiles.commands.RecursiveFolderCommand
(see the attached snapshot)
Comment 1 dmladek 2003-10-16 14:11:34 UTC
Created attachment 11885 [details]
snapshot of Exception
Comment 2 dmladek 2003-10-16 14:17:11 UTC
And there was at the begining 450 files (including all files from all
CVS subdirs)
Comment 3 Martin Entlicher 2004-01-22 15:01:08 UTC
This problem should be fixed by the cache redesign (issue #32089).
Some solution would have to be created for 3.6.
Comment 4 dmladek 2004-02-26 06:49:38 UTC
I downgrafing the priority for this bug:
it is not probably very common scenario, this I won't push you to
fixing separately this problem if it will be solved by introducing
your new cache:-)
Comment 5 dmladek 2004-02-26 07:19:25 UTC
BUT, there is more general and typical use-case which is clearly
recognizable on performance:
  VCS-Output is significantly slow if you CVS-operate bigger amount of 
  files (>500 files). In fact it is regresion. For more details see the 
  issue #40505
Comment 6 Martin Entlicher 2004-04-20 14:38:21 UTC
3.6 is out, re-scheduling for promotion D (4.0).
Comment 7 Martin Entlicher 2004-04-30 10:49:51 UTC
Dependency on cache redesign issue added.
Comment 8 Martin Entlicher 2005-01-05 19:46:40 UTC
Needs to be tested with the new cache impl., it might be fixed.
Comment 9 _ pkuzel 2005-01-17 17:36:43 UTC
My test case:

    public static void main(String[] args) throws Exception {
        File root  = new File(System.getProperty("java.io.tmpdir") +
File.separator + "issue36643"); // NOI18N
        generate(root, 6);
    }

    static void generate(File root, int deep) throws Exception {
        root.mkdir();
        for (int i=0; i<deep; i++) {
            File dir = new File(root, "dir" + i);
            File file = new File(root, "file.txt");
            file.createNewFile();
            generate(dir, deep-1);
        }

    }

1957 files

Memory consumption  went to 124/127 and then back to 24/127.

Unfortunately then I was bittem by leak of my anger when I was
requested many times for commit message. Fortunately it failed after
while. Martin claims it's :local: method specifics problem.
Comment 10 Martin Entlicher 2005-04-05 17:01:09 UTC
According to the pkuzel's comment this ought to be fixed in 4.1?
BWT: the problem with many commit dialogs is already solved (although it's still
confusing when one loads the template).