RE: [cdt-dev] Major PDOM changes in HEAD

[Ed Warnicke <eaw@xxxxxxxxx>]

Doug,
	Doesn't a DB per workspace sort of kill any future hopes
of pre generating the DB offline?  I'm not talking about remoting here,
just plain old fashion prepopulating...

Ed
On Thu, 2006-05-18 at 21:26 -0400, Doug Schaefer wrote:
> Actually, the PDOM was always in the .metadata directory. Now, instead of
> having one database per project, there is only one database per workspace.
> 
> And because the PDOM is memory mapped into the Eclipse process, it has to be
> local. Right now I'm having enough trouble squeezing reasonable performance
> out of a strictly local architecture. I have no idea how to properly do
> remote projects. For that, I'll need some help :).
> 
> Doug Schaefer, QNX Software Systems
> Eclipse CDT Project Lead, Tools PMC member
> http://cdtdoug.blogspot.com
>  
> 
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Greg Watson
> Sent: Thursday, May 18, 2006 9:07 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Major PDOM changes in HEAD
> 
> Doug,
> 
> I know this is a bit left of base, bit I wonder if this change is  
> going to make support for remote projects more difficult? I had  
> imagined that if the PDOM database was stored in the project  
> directory then it should be able to be generated on the remote  
> machine, but still be visible to Eclipse running on the local  
> machine. If the database is stored at the workspace level then I  
> don't think this approach will work any more (unless the whole  
> workspace is remote.)
> 
> Just a thought.
> 
> Greg
> 
> 
> On May 18, 2006, at 5:47 PM, Doug Schaefer wrote:
> 
> > Hey gang,
> >
> >
> >
> > I have made some major last minute changes to improve PDOM  
> > performance. First, the PDOM database is now per workspace instead  
> > of per project. This will allow projects to share indexing results  
> > with each other. It may also lead to weird results but, for the  
> > moment, it is worth it.
> >
> >
> >
> > Also, I have done some caching so that the indexer accesses the  
> > PDOM less often during a parse. This has given me a Firefox index  
> > time of 13 minutes compared to 53 minutes in CDT 3.0.2. This may  
> > fluctuate as I spend the rest of this release and 3.1.1 making it  
> > more accurate, but it is a huge step forward.
> >
> >
> >
> > At any rate, I apologize for the late churn and promise to make  
> > sure indexing and the features that use the index remain robust for  
> > our GA release.
> >
> >
> >
> > Cheers,
> >
> > Doug Schaefer, QNX Software Systems
> >
> > Eclipse CDT Project Lead, Tools PMC member
> >
> > http://cdtdoug.blogspot.com
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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