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.
Summary: | org.netbeans.modules.editor.impl.ActionsList.<init>() calls DataObject.find() and takes too long | ||
---|---|---|---|
Product: | editor | Reporter: | tnleeuw <tnleeuw> |
Component: | Settings | Assignee: | David Strupl <dstrupl> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | aquaglia, epdv, misterm |
Priority: | P3 | Keywords: | PERFORMANCE |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | 155530 |
Attachments: | nps snapshot |
Description
tnleeuw
2010-12-12 09:51:19 UTC
Created attachment 103979 [details]
nps snapshot
As you can see from reports 452749 and 455173 the culprit is DataObject.find(). The question is whether it should be called from AWT EDT but when using default lookup (or other lookups which use sfs) this is not avoidable. Look at org.netbeans.modules.editor.impl.ActionsList.<init>() I don't see much reasons why constructor shall initialize something from disk. Just return the instance and that is it. If DataObject.find is ok to take 9 seconds I don't think there is anything we can do in the editor to avoid this delay. The problem is obviously not in the constructor. There are other calls of ActionsList.convert or subsequently ActionList.convertImpl which are done in AWT. E.g. when you invoke popup we need to convert the actions to show them. Closing as wontfix. If someone sends a reasonable patch we can apply it. I've got a slowness report today (#657471), and after looking at it, I noticed one time-consuming issue is handling of FileObjects in org.netbeans.modules.maven.execute.DefaultReplaceTokenProvider.extractFileObjectsfromLookup(): As it seems to scan whole SFS, it's very time-consuming, and it seems to be used several times, i.e. for every files or usage search, so IMHO the resulting FileObject array should probably be cached. I don't expect problems with memory usually, as scanning seems to happen often, so memory will be occupied nevertheless, with probable side effects like memory leaks or making GC busy (resulting in even more time consumption). |