Bug 289298 - [content assist] Run completion proposal computers in parallel
Summary: [content assist] Run completion proposal computers in parallel
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.5   Edit
Hardware: All All
: P3 enhancement with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: JDT-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-13 09:27 EDT by Stephan Herrmann CLA
Modified: 2009-09-14 11:08 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Herrmann CLA 2009-09-13 09:27:18 EDT
In a similar vein as bug 151053 is discussing for the JDT/Core,
I was wondering whether completion and quick fix could be sped up
by parallelizing computations.

It looks like the following methods could be natural places for 
parallization:

  JavaCorrectionProcessor.collectCorrections(IInvocationContext, IProblemLocation[], Collection)

  ContentAssistProcessor.collectProposals(ITextViewer, int, IProgressMonitor, ContentAssistInvocationContext)

In case parallizing within each category would be more effective alternatively 

  CompletionProposalCategory.computeCompletionProposals(ContentAssistInvocationContext, String, SubProgressMonitor)

could be a candidate.

All three methods loop over some contributors which naively spoken
might work independently. Only for correction collectors the protocol
obviously requires some changes (regarding fields fLocations and fDescriptor,
which cannot be shared among invocations).

I haven't done any specific experiments at this stage. Basically asking
whether this issue has been discussed before, and whether anyone would
see it as a promising direction.
Comment 1 Dani Megert CLA 2009-09-14 06:45:34 EDT
See also bug 251156.
Comment 2 Stephan Herrmann CLA 2009-09-14 07:32:14 EDT
(In reply to comment #1)
> See also bug 251156.

Thanks for the link. I just skimmed through bug 251156. 
Tyring to be perfectly clear, this is the major difference I'm seeing: 
I'm not speaking of pushing computation to the background, 
but of better utilizing multiple CPUs during computation.
Users would still have to wait until all computations are done.
My intention would be to come up with something much simpler than their patch.

I saw that the guys in bug 251156 actually patched one of those very loops
that I had looked at, too. Maybe we can benefit from their experience 
in this point. Also the issue of sorting is common to both bugs.

Actually, parallelizing completion processors would stick to the design
that each single processor should be very quick. The goal would only be
to reduce the impact of having several/many processors.

OTOH, I wasn't focussing on completion alone, but also corrections.