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.
This issue was originally marked as duplicate of issue 168389, that is already resolved. This issue is still valid, so this seems to be another issue, but it might be related. Build: NetBeans IDE Dev (Build 200909301401) VM: Java HotSpot(TM) Client VM, 11.2-b01, Java(TM) SE Runtime Environment, 1.6.0_12-b04 OS: Windows XP, 5.1, x86 User Comments: err: "undo" in editor Maximum slowness yet reported was 3968 ms, average is 3968
Created attachment 88790 [details] nps snapshot
Probably profiler guys should look at this, since this report does not make sense.
No profiler code seems to be involved, not much to do on our side (even though the report doesn't make sense to you). You should probably consult it with guys from performance team...
O.K.
Could you take a look at it again? Some new snapshots was added and could help you. Thanks
Build: NetBeans IDE Dev (Build nbms-and-javadoc-4040-on-091003) VM: Java HotSpot(TM) 64-Bit Server VM, 14.1-b02-90, Java(TM) SE Runtime Environment, 1.6.0_15-b03-219 OS: Mac OS X, 10.6.1, x86_64 User Comments: Maximum slowness yet reported was 23285 ms, average is 8714
Created attachment 89248 [details] nps snapshot
This issue already has 6 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=159483
Only snapshot-276301.nps seems to be meaningful, problem in org.netbeans.api.java.source.SourceUtils.getFile() calling ClassPath.findAllResources() in AWT.
Hm, seems like several intermixed problems: -reports 276301, 277903, 277920, 277930 and 277932 which were duplicated to this exception report (#159483) were actually duplicate of exception report #159291. I moved them there. I have no idea whatsoever why the exception reporter duplicated them to this exception report. This should be fixed in the exception reporter (so that we do not waste time splitting/joining/evaluating obviously incorrect duplicates). Note that even the so called suspicious methods were different. -several other reports spent quite a lot of time in RequestProcessor$SlowItem by filling stack trace to exceptions. I understand this is some debugging aid - is it really so useful to overweight the slowness of the IDE and time of the people evaluating the slowness reports? Wouldn't it be better to enable it only when needed by a cmd. line option? I quickly peeked at (some of) the remaining reports, and I did not see anything that would relate to Java - passing to performance to split/reassign to appropriate components.
276350 - duplicate of YAGL in masterfs, issue 172865 275679 - is somehow unusable (just 80ms) recorded and only from 3 samples. 275493 - is the RP stuff - can be fixed by using new constructor of RequestProcessor that disables the fillStackTrace 274092 - is again slow RP's fillStackTrace() 272178 - is broken for some reason (92ms does not correlate with 42 snapshots) In summary, this is either fixed, won'tfix or not present in production code. Closing.