Re: [cdt-core-dev] STRUCTURAL_PARSE in the outline confusions

[Douglas Schaefer <dschaefe@xxxxxxxxxx>]

Do you have a sense on how this will impact all of the clients of the 
CModel? Does this have a chance to spread our performance woes to clients 
who used to avoid such woes?

Doug Schaefer, IBM's Eclipse CDT Architect
Ottawa (Palladium), Ontario, Canada



"Alain Magloire" <alain@xxxxxxx> 
Sent by: cdt-core-dev-admin@xxxxxxxxxxx
08/10/2004 04:06 PM
Please respond to
cdt-core-dev


To
cdt-core-dev@xxxxxxxxxxx
cc

Subject
[cdt-core-dev] STRUCTURAL_PARSE in the outline confusions






Bonjour

   Some debates are taking place in bugzillas on the issue of the 
outliner,
I think it should have a wider audience, or at least I should clear some 
issues.

  Basically for hysterical raisins, we have a setting in the preference
page:

   - Follow #include's for the outliner view.



This has nothing to do with the outliner.   The outliner is just a client 
of the
of the core model and it listens to ICElementDelta changes to refresh its 
view.

What's going on  is when a CEditor starts it also quick off a monitor 
thread call "reconciler",
that will do parsing on the working copy buffer of the Editor.  the 
"reconciler" thread
listens to changes of the editor and starts a parse() on the working copy 
.. this can
be very intensive (the reconciler can be trigger many times as you type). 
Deltas are build/trigger
to the Core Model listeners; C/C++ View, actions etc ... including the 
outliner(this is when you see it refresh)
are all listeners and react to the deltas.


For performance reason, we decided to use the QUICK_PARSE instead of the 
STRUCTURAL_PARSE
The STRUCTURAL_PARSE is better and can provide the Core Model with much 
more usefull
data (macros etc ...) so actions like wizards, opentypes, add include even 
the debugger can
do much more usefull things  but the price was way to high.


So ... what is the problem again ... you ask:

The problem is ___how___ this was implemented, the toggle was done deep 
inside
the core model pushing the requirement of one service to all others.

I'm proposing a solution, lets do the QUICK_PARSE for the working copy 
parse(IWorkingCopy) by
default(unless the setting is toggle) and keep the STRUCTURAL_PARSE for 
the normal
file system parsing (ITranslationUnit).

This will still give us good performance, since the problem was the 
reconciling thread
parsing too often but give reasonnable info/data for other clients that 
needs it, since
they do not really care about in memory copies.


Comments ?


_______________________________________________
cdt-core-dev mailing list
cdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-core-dev