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: | Regression on startup time ( ModuleSystem.readList finished ) | ||
---|---|---|---|
Product: | profiler | Reporter: | Marian Mirilovic <mmirilovic> |
Component: | Base | Assignee: | Tomas Hurka <thurka> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | issues |
Priority: | P2 | Keywords: | PERFORMANCE |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Startup log file 200702281900 - with profiler
Startup log file 200702271900 - without profiler |
Description
Marian Mirilovic
2007-03-01 07:47:25 UTC
incomplete till reason of this regression is known to be caused by profiler. Mariane, can you please attach the startup log? Created attachment 39034 [details]
Startup log file 200702281900 - with profiler
Created attachment 39035 [details]
Startup log file 200702271900 - without profiler
OK, we should find this sooner. That's my fault we did not verified this. -J-Dorg.netbeans.log.startup=print shows noticeable delay on ModuleInstall of org.netbeans.modules.profiler/1 (almost 2% for first start). Then there are small additions for each module - module.xml is parsed, manifests sections are processed, more items on layers and so on. I am not sure how much work we really need to do in ModuleInstall. It seems that it initializes too many classes. It seems that there is some plugability hook to change profiler implementation, why (btw depending on sun.misc.Service because j.u.ServiceLoader is there since 1.6)? These classes probably have some eager inits. The biggest part of this module install is spent in Profiler.getDefault, next significant part is loadGlobalFilters (DOM parsing?) Another slower part of startup is processing of keyboard shortcuts where we added new profiler actions - classloading, settings names, icons. I am not sure if we can make init of actions more lightweight. Re actions: Swing actions should be a bit cheaper that subclasses of SharedClassObject Loading of XML files moved out of Module.restore(). Please measure it again. Fixed for M8. verified in NB Dev (200703271800) |