eclipse-qvtd-bot
commented
2 weeks ago By Ed Willink on Sep 17, 2016 03:45
(In reply to Ed Willink from comment #0)
There is a depressing amount of Collection copying
The inter-mapping connections, and the initial allInstances buffers were particularly bad. Using Iterables/Lists rather than Sets and Iterators contributed to a major CG speed up for EXE 2016. Similar interpreted speed up pending.
Support for Active Connections, see Bug 500962, should contribute further.
| --- | --- | | Bugzilla Link | 500299 | | Status | NEW | | Importance | P3 normal | | Reported | Aug 25, 2016 14:01 EDT | | Modified | Sep 17, 2016 03:45 EDT | | Depends on | 500962 | | Reporter | Ed Willink |
Description
Examining typical CGed execution reveals:
Many distinct eObject2xxx incuring multiple HashMap$Node per EObject. Better to somehow share via a unified co-EObject. Perhaps a unified slottedEObject internally. Perhaps an linear EObjectIndex passed so that co-EObject lookup is cheap. Whatever, try and avoid any HashMap$Node.
The ObjectManager has many tiny Maps. Introduce a SmallMap class so that up to ? 5 entries use Array slot searches. If the search uses object equality then there are no hashCodes so even 10 entries may be faster as an array. Only big Maps delegate to a true Map. Whatever, try and avoid most HashMap$Node. Potentially all unifiable in a slotted-EObject.
There is a depressing amount of Collection copying, particular Set formation for known unique lists. Probably suitable for lazy collections.