Project loading (Was: KDevelop 4.0 Release)

[Andreas Pakulat]

On 07.09.08 23:41:18, Aleix wrote:
> On Sun, Sep 7, 2008 at 11:22 PM, David Nolden <zwabel at googlemail.com> wrote:
> 
> > Am Sonntag, 7. September 2008 22:54:48 schrieb Aleix:
> > > > What I'd like to have in KDevelop4:
> > > > - Faster CMake parsing, or even better disk-caching of the results
> > >
> > > I'm not really sure being faster on project loading should be a big
> > concern
> > > for the .0 release (I'd better prefer to have it fully working, which is
> > > mostly for now).
> > > Said that, saving the ProjectItemModel's tree might not be that hard...
> >
> > Well, the problem is that we can have multiple projects, currently I have 4
> > loading on every startup, and while it does go relatively fast until they
> > are
> > loaded, I always have to wait for it. But KDevelop4 in its base, especially
> > the whole cpp support stuff including quickopen etc., nearly do not need
> > _any_ load time to be functional. Since we're competing with Eclipse, we
> > could make that a big advantage: A development-environment that is
> > light-weight with nearly instant startup time.
> >
> > I would like KDevelop4 to be light-weight, like a much more powerful
> > drop-in
> > replacement for kate, where the user doesn't have to think whether he wants
> > to take the overhead of firing it up.
> >
> Maybe the problem here is opening projects on startup.

Manuel has a patch in the pipeline to make that a tad bit faster. Whats
really missing is a way to tell the user that a project is being loaded
right now and that he needs to wait a bit if he wants to use it. There's
never going to be a way of being as fast as kate when projects are
involved.

I've thought about putting the tree into the UI earlier, the problem is
that this will have an impact on UI performance because populating the
tree while it is in a view causes updates on that view - wether its open
or not.

> Even if we cached the project model, we would have to parse in case the any
> part of the project has been modified.

I don't see the benefit of storing the project model. Creating the items
is not an expensive thing. Whats expensive is all the parsing that you
do ;) 

And thats the part that maybe should be stored, especially things like
the result of parsing FindKDE4Internal.cmake and other find-modules.

The question that comes to my mind here is wether it would be possible
to analyze a CMakeLists.txt based on a DUChain model of that file. That
is can you store enough of the original information in DUChain to get
the important information out of it later on. That would give you the
"storage" part for free.

> note that the cmake support relies on the system configuration (e.g. for
> checking env variables, configuration files, etc.)

You mean in which environment I start kdevelop4 has an impact on project
parsing? Thats not good - at least env-var wise we do have a better
option that should be used instead. I mean the system env should be used
as base information, but cmake should support our env-var-widget to
choose a different set of envvars.

Andreas

-- 
You dialed 5483.