Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "PDE/4.4TargetChanges"
< PDE
| Line 9: | Line 9: | ||
* TargetPlatformService now holds on to a resolved target definition for fast lookups | * TargetPlatformService now holds on to a resolved target definition for fast lookups | ||
* p2 target locations are not marked as dirty on creation avoiding pinging remote sites | * p2 target locations are not marked as dirty on creation avoiding pinging remote sites | ||
| + | * Binary compatible API change in org.eclipse.pde.internal.core.target.TargetPlatformService.getWorkspaceTargetHandle() we cannot initialize the plug-in registry from this method as the order has changed. Previously, the models were created from preferences and the target was based on that. Now, the models are based on the target. | ||
Still to finish: | Still to finish: | ||
Revision as of 17:32, 29 August 2013
Changes relating to bug 283731 - [target] Remove target state dependence on preferences
Changes made:
- Improved tracing, no more cache option, new modeloption, displays model creation time
- Deprecated all target platform preferences from ICoreConstants (internal)
- Deprecated TARGET_CHANGED and ENVIRONMENT_CHANGED from IModelProviderEvents (API)
- PDEState is no longer cached (<100 ms performance hit for standard platform, >200ms gain for large target)
- Changing target platforms now does not do a removal/add/reset, instead all content is reset
- TargetPlatformService now holds on to a resolved target definition for fast lookups
- p2 target locations are not marked as dirty on creation avoiding pinging remote sites
- Binary compatible API change in org.eclipse.pde.internal.core.target.TargetPlatformService.getWorkspaceTargetHandle() we cannot initialize the plug-in registry from this method as the order has changed. Previously, the models were created from preferences and the target was based on that. Now, the models are based on the target.
Still to finish:
- Look at performance bottlenecks (see below)
- How to recover from cancelled job
- Look at ways to delay any p2 operation that is long running unless user can cancel
- Provide progress reporting when loading models in wizard or preference page
- Better recognize when target content on disk has changed
- Can feature loading even happen first?
- Provide target status information on preference page, target state view and target status line
Performance impacts:
- Removing state caching improves performance for larger targets (1000+), slight hit for smaller targets (500-)
- Model creation is about 100ms longer to resolve target platform
- 100ms from above could be gained back by not reading the manifest files 2 (or 3 times)
- p2 targets are very fast if everything is downloaded, any missing files cause long running operations
- p2 targets were changed to not ping remote sites on creation