Description Ian Tewksbury 2010-04-26 09:41:00 EDT

Due to the improvements to content assist made by Bug 258999 a regression in the running time of StructuredTextViewerConfiguration.getContentAssistant was detected in an adopter product. This causes the initial opening time of an editor to be sown down.  After investigation this regression was tracked down to three things.

1. Loading the default preferences was moved up from the line style providers to the content assistant.  Therefor this was not really a regression in the loading time of the editor just moving where this takes place

2. The parsing of the legacy content assist extension points takes place in the constructor of StructuredContentAssistProcessor.  This load appears to take 10-30ms for each processor construction and there is a processor constructive for each partition type in any given content type.  Thus this time was adding up to a more significant 200-300ms during editor opening.  My solution for this was to move this initial loading of the legacy extension points to the first time they are needed, which is the first time content assist is invoked, this only adds 10-30ms to that very first invocation (could not notice a difference to the user) and is in line with the way we used to load these extensions when they were not legacy thus would not be a regression in content assist invocation time, and again there is no noticeable slow down to the user and it only occurs on the very first invocation in any given partition type.

3. The parsing of the new extension points has been seen to take anywhere from 50 to 100ms.  While not huge these type of slow downs add up and helps to slow down the initial opening of the first SSE editor to be opened.  The solution here is to move the parsing of the new extension points off on its own thread so as not to block the loading of the first editor to be opened.  Note this parsing only has to happen once for the entire workspace.  I was also careful to make sure that if somehow the user manages to invoke content assist before the parsing thread has finished the content assist will wait for the parsing to finish.  But in all of my testing I was never able to invoke content assist quickly enough to where the extension points had not already been parsed.

In my profiling I observed the following execution times for StructuredTextViewerConfiguration.getContentAssistant:

Without Patch: 552ms, 593ms, 531ms
With Patch: 390ms, 453ms, 421ms

A noticeable improvement.

Patch to follow that passes all JUnits and a smoketest of the content assist.