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.
ShadowChangeAdapter and its impl. of OperationListener causes strange performance penalty. See #39213 and its attachment with output from OptimizeIt.
I'll fix it after trying to write some performance tests.
Created attachment 13398 [details] This is going to be my fix. Radek please review.
Great, I'll verify it today.
Checking in loaders/src/org/openide/loaders/BrokenDataShadow.java; /cvs/openide/loaders/src/org/openide/loaders/BrokenDataShadow.java,v <-- BrokenDataShadow.java new revision: 1.6; previous revision: 1.5 done Checking in loaders/src/org/openide/loaders/DataShadow.java; /cvs/openide/loaders/src/org/openide/loaders/DataShadow.java,v <-- DataShadow.java new revision: 1.8; previous revision: 1.7 done Processing log script arguments... More commits to come... RCS file: /cvs/openide/test/unit/src/org/openide/loaders/DataShadowBrokenSlownessTest.java,v done Checking in test/unit/src/org/openide/loaders/DataShadowBrokenSlownessTest.java; /cvs/openide/test/unit/src/org/openide/loaders/DataShadowBrokenSlownessTest.java,v <-- DataShadowBrokenSlownessTest.java initial revision: 1.1 done RCS file: /cvs/openide/test/unit/src/org/openide/loaders/DataShadowSlowness39981Test.java,v done Checking in test/unit/src/org/openide/loaders/DataShadowSlowness39981Test.java; /cvs/openide/test/unit/src/org/openide/loaders/DataShadowSlowness39981Test.java,v <-- DataShadowSlowness39981Test.java initial revision: 1.1
Great! The performance improvement is huge. I measured deleting of a folder containing a thousand files in a mounted FS in explorer. The results are: nb351: 3330ms trunk build 200402121900: 9583ms trunk build 20040213-0849 (with the fix): 2692ms
I hoped this would be a happy-end! The code in 3.5 is very unoptimal, but was executed asynchronously (3333ms), but this disallowed any unit testing and that is why during 3.6 release I changed it to synchronous (9s), I knew that it is inefficient, but "premature optimalization is source of all evil" and I let it be. The current version changes the data structures to be effecient - that is why we are better than 3.5 (2700ms).