Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 351438 - performance problems with ExportedPackageImpl constructor
Summary: performance problems with ExportedPackageImpl constructor
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Framework (show other bugs)
Version: 3.7   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.7.1   Edit
Assignee: Thomas Watson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 351258
Blocks:
  Show dependency tree
 
Reported: 2011-07-07 08:40 EDT by Thomas Watson CLA
Modified: 2011-07-08 16:39 EDT (History)
5 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Watson CLA 2011-07-07 08:40:38 EDT 
Consider backporting performance fix to 3.7.1.

+++ This bug was initially created as a clone of Bug #351258 +++

Build Identifier: 3.7

The ExportedPackageImpl constructor, which gets called numerous times in most of the package admin service, is one of the top performance hotspots.

During the constructor call, Version.toString() is called. Even after Version.toString() is optimized (324331), this remains a hotspot, as it seems that Version objects don't seem to be reused, thus negating the benefit of the Version.toString() optimization.

The specVersion computation doesn't appear to be a central operation in ExportedPackageImpl, and yet each constructor call incurs a call to Version.toString().

I tried out a change where specVersion is lazily computed (computed only if getSpecVersion() is called), and that leads to a *substantial* performance improvement. Would it be possible to have this fixed and optimized that way? I can provide a patch if needed. Thanks!


Reproducible: Always