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

[John Camelon <jcamelon@xxxxxxxxxx>]

Concern 1: 
Without exposing the full cross-reference
information out through the CModel API, a frequent pattern may arise like:

• Editor is saved, resource change event causes CModel to be rebuilt w/STRUCTURAL_PARSE
• Notification sent out via element delta
• Client has to reparse the file again to get the same information that the CModel threw away.  

Concern 2: 
If you switch between QUICK_PARSE (reconcile)
and STRUCTURAL_PARSE (save), the tree may change quite drastically once
you do a save.  QUICK_PARSE is an approximation, STRUCTURAL_PARSE
is precise.  

Concern 3: 
STRUCTURAL_PARSE requires include paths
in order to work properly.  Since we have not done integrations to
all toolchains as of yet, we would be disabling the outline view out of
the box for non-GNU clients.  STRUCTURAL_PARSE/COMPLETE_PARSE without
include paths is even less accurate than QUICK_PARSE.  

Concern 4: 
Without having incremental parsing,
there is no way we will be fast enough to make STRUCTURAL_PARSE not noticable.
 Try it out on a project with files referencing numerous inclusions
and see for yourselves.  The difference in performance between QUICK_PARSE
and STRUCTURAL_PARSE can be several orders of magnitude, depending on how
deep the inclusions go (particularly with templates). 

Concern 5: 
Irregardless of whether someone uses
the hierarchy or browsing views, we are impeding our scalability out of
the box.  Ideally, the indexer should be the only component doing
a COMPLETE or STRUCTURAL parse on resource change event.  The more
clients parsing the same files at the same time using the symbol table
means more garbage collections or even OutOfMemoryErrors.  

It is my belief that we need to make
the best with what we have in the short term (2.1), for the sake of scalability
and the performance of our primary workflows.  In my opinion, this
is more important than rounding out our feature set.  Alain, what
APIs in particular in the AST do the features listed in your email require
to be exposed through the CModel?

JohnC
www.eclipse.org/cdt

cdt-core-dev-admin@xxxxxxxxxxx wrote on 08/10/2004
04:06:42 PM:

> 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