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.
The exception reporter duplicates the following "slowness" reports: 649777 649140 648527 648520 648412 648088 647523 646466 646155 644907 644893 644095 643567 643061 642939 640880 639305 638986 637487 634294 633521 630895 630826 629185 627318 627075 627040 627033 626863 624104 624047 624043 624038 623836 623625 623620 623488 623209 622812 622480 621952 621623 621620 619400 619206 618640 618623 612829 611730 611728 608342 606508 605834 605386 602433 594697 593741 592078 590743 590576 589377 587011 585186 579246 574931 574849 570418 569454 568429 564229 560207 558951 557536 556712 550861 550783 550252 to: http://statistics.netbeans.org/exceptions/detail.do?id=183632 But, many of them appear to be unrelated, I had to manually go through these slownesses and had to fill these reports in addition to the original one: 197728, 197729, 197730, 197731, 197732, 197733, 197734, 197735, 197736, 197737, 197738, 197739, 197740, 197741, 197742, 197743, 197744, 197745, 197746, 197747, 197749, 197750, 197751 which was a tedious manual tasks, benefits of which will be lost if the exception reporter will continue falsely assign the slownesses to the original report.
Sadly, all these have been duplicated correctly according to current algorithm; they all have the same suspicious method: org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.exists So we need to figure out how to solve these cases (add this particular method to innocent, or is there a bug in method detection algorithm?, ...) in cooperation with someone who has deeper insight in slowness than me.
After discussion with perf team, we added org.netbeans.modules.masterfs.filebasedfs.fileobjects package to innocent list; this should give more relevant suspicions method and thus fix incorrect duplication.