Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 357268 - Eclipse contexts: reduce overhead of invalidations
Summary: Eclipse contexts: reduce overhead of invalidations
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Runtime (show other bugs)
Version: 4.2   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: 4.2 M3   Edit
Assignee: platform-runtime-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-09 14:04 EDT by Oleg Besedin CLA
Modified: 2011-10-31 14:19 EDT (History)
4 users (show)

See Also:


Attachments
Patch (29.99 KB, patch)
2011-09-09 14:16 EDT, Oleg Besedin CLA
no flags Details | Diff
Additional change - prevent leaks (9.69 KB, patch)
2011-09-19 11:43 EDT, Oleg Besedin CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Oleg Besedin CLA 2011-09-09 14:04:15 EDT
From preliminary look at 4.x performance tests we spend a sizable portion of time re-calculating dependencies when value in the context change.

This is "as expected", but something that stands out in profiler results is that we spend a good portion of time removing "old" links (which are two-way links) between eclipse context entries and computations (IContextFunctions and IRunAndTrack).

It is possible to reduce the work we spend on "invalidation" of links. The basic idea is to not to remove links between context elements and computations but rather:
 - mark the computation is "invalid" and ignore/overwrite it as we come across it again
 - keep non-active computations referenced via WeakReferences so that they can be garbage collected.

One other idea is that, in practice, in most cases we don't "reduce" the set of dependencies of a computation. I.e., if we had a dependency on A, B, and C, chances are that subsequent calculations will expand the set of elements we depend on, but rarely will contract it. 

Combining those ideas we can:
- replace our two-way links with one way links (we don't need to remove existing dependencies from the computation side)
- keep ValueComputation and their dependencies unless the definition of ICF chnages (we'll simply mark them as "dirty" and re-calculate lazily when asked)
- replace one-by-one removal of listeners with a bulk cleanup (for instance, when > 50% of listeners becomes marked as invalid).
- significantly simply code that links context values and computation.

I used an open&close performance test to gauge the effects of this change. On my computer this results in about 40% improvement in CPU time for that test.
Comment 1 Oleg Besedin CLA 2011-09-09 14:16:41 EDT
Created attachment 203082 [details]
Patch

This is the milestone week (M2), I plan to apply the patch once we are open for M3.
Comment 2 Oleg Besedin CLA 2011-09-19 11:43:35 EDT
Created attachment 203610 [details]
Additional change - prevent leaks

The first patch was leaking listener references.
Comment 3 Eric Moffatt CLA 2011-09-19 15:34:54 EDT
Oleg, what's the overall performance gain from this patch ?
Comment 4 Oleg Besedin CLA 2011-09-19 16:01:55 EDT
(In reply to comment #3)
> Oleg, what's the overall performance gain from this patch ?

About 20% of the CPU for { open & close view } cycle.

It also significantly simplifies code that manages dependencies for RaTs and context functions.
Comment 5 Oleg Besedin CLA 2011-10-31 14:19:55 EDT
Patches were released in M3.