RE: [cdt-dev] Introducing the PDOM

[Ed Warnicke <eaw@xxxxxxxxx>]

Quick question... how does this relate to the multiple build
target problem?  The preprocessor output (and thus the indexing)
may vary from build target to build target... is the PDOM going
to be flexible enough to handle that?

Ed
On Mon, 2005-10-03 at 10:00 -0400, Doug Schaefer wrote:
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> > Behalf Of Chip Chapin
> > Sent: September 30, 2005 6:47 PM
> > To: CDT General developers list.
> > Subject: Re: [cdt-dev] Introducing the PDOM
> > 
> > Doug,
> > 
> > This certainly sounds promising as being a way forward.  I don't know
> > enough CDT internals to judge whether this is the best solution, but
> > indexing issues are the biggest problems we have with CDT here,
> > especially the massive amounts of time it takes.
> 
> That's a common experience, especially for people using the CDT on large
> projects. The main issue I've seen is that we've been parsing like a
> compiler does, a complete parse for each compilation unit. It's super
> accurate, but in the end, we end up parsing the same header files over and
> over again. If we can get it down so that we only have to parse each of them
> once, and even share the results of that down stream to the customers of
> SDKs for example, then we'll see huge gains. That is the theory, anyway.
>  
> > For our needs I think we would be very interested in being able to plug
> > in our own dbms interface, at least at some point.
> 
> We'll definitely keep that option open. We'll start with Derby, an embedded
> SQL database from Apache, but I want to make sure that people can swap that
> out for their own persistence technologies.
> 
> > And I think there's a good chance that one or more folks here at Google
> > would be available to help out.
> 
> That would be excellent. If anyone knows about indexing, it would be Google
> :)
> 
> Cheers,
> Doug
> 
> > Chip
> > 
> > 
> > Doug Schaefer wrote:
> > 
> > >Hey gang,
> > >
> > >As the next step in the evolution of the CDT DOM, I am starting work on
> > >a persistence strategy that will allow us to greatly reduce the amount
> > >of parsing we do in both the indexer as well as the features that use
> > >the DOM (content assist, open decl/def, etc). The idea is to stow away
> > >names and bindings from the DOM into a database to allow for binding
> > >resolution and decl/ref searches to get information from this database
> > >instead of having to reparse. I am calling this database the PDOM, or
> > >Persisted DOM.
> > >
> > >The premise is that database look-ups will be faster than building the
> > >AST for header files over and over again. That should finally solve our
> > >indexer performance problems. And if not, I am making it so that we can
> > >simply toss away the whole thing and take another tact without
> > >disturbing the status-quo.
> > >
> > >I am producing a slide package on all this that I will present at the
> > >CDT developer conference next month. In the meantime, you will notice
> > >code going into the CVS repository as I start trying out these ideas in
> > >optional plugins: org.eclipse.cdt.pdom.core and org.eclipse.cdt.pdom.ui.
> > >
> > >If you have any questions, opinions, or even better - would like to help
> > >out, please let me know. I am certainly open to opinions that make me
> > >think this is a bad idea and save me all this work :)
> > >
> > >Cheers,
> > >Doug
> > >
> > >_______________________________________________
> > >cdt-dev mailing list
> > >cdt-dev@xxxxxxxxxxx
> > >https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >
> > >
> > 
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev