Re: [cdt-dev] Introducing the PDOM

[Sumit Sarkar <sumit.sarkar@xxxxxxxxx>]

Hi Doug,

In our HP Remote Development product, we are facing the problem, that "indexer" is reading the local header files (if they exist) to build the DOM. In your new architecture, if you consider a way to map the local header files with the remote (or from other location), that will be great. That way, it will be easier for us to use the remote header files to index the remote project. I am not sure whether CDT 
3.0 has already this feature or not.

Thanks,
sumit

On 9/28/05, dschaefer@xxxxxxx < dschaefer@xxxxxxx> wrote:

Absolutely. I'm currently looking at Derby, an Apache embedded SQL database
that has shown some good performance. I'm still learning SQL but I think you
can merge tables together quickly. So you could create a PDOM in one
project, one containing all your header files for example, and package it up
for delivery, and auto-merge it into the PDOM for users' projects.

I'll record it as a requirement and we'll definitely give that a try as this
thing matures over the upcoming weeks.

Cheers,
Doug

"Treggiari, Leo" <leo.treggiari@xxxxxxxxx> said:
> Hi Doug,
>
> I think it is a GOOD idea.  If we have CDT-wide tool-chain definitions,
> then maybe the tool-chain could provide a pre-built PDOM for its own
> header files.  So, you might want to consider being able to handle
> multiple PDOMs for a single project.
>
> Regards,
> Leo
>
>
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx ]
> On Behalf Of Doug Schaefer
> Sent: Wednesday, September 28, 2005 5:06 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] Introducing the PDOM
>
> 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