KDevelop: General direction and UI - don't worry

Andreas Pakulat apaku at gmx.de
Wed Nov 5 09:43:55 UTC 2008


On 05.11.08 08:19:50, Manuel Breugelmans wrote:
> On Monday 03 November 2008 23:33:38 David Nolden wrote:
> > Am Montag, 3. November 2008 21:23:12 schrieb Alexander Dymo:
> > > I'd personally expect the finished KDevelop4 to
> > > 1) start fast
> > > 2) open any kde/cmake project from the directory on my disk without much
> > > question
> > > 3) load that project as fast as possible
> > > 4) compile it and compile parts of it
> > > 5) set a breakpoint, launch debugger and stop on it
> > > 6) give me code completion
> > > 7) rename class/method without much effort from my side
> > > 8) check in and out my project from any modern VCS
> > > etc.
> > > etc.
> >
> > I completely forgot to respond to these technical aspects. In general you
> > have quite well matches exactly what I wish too.
> >
> > So let's see where we are:
> > 1 - Is the case
> 
> Depends, I can heavily influence start time by increasing open files. From boot 
> to both kdevelop + kdevplatform projects loaded takes 4 seconds with zero 
> files, 10 seconds with 30 (cpp) files opened. That's too much of a difference. 
> Both numbers are from a hot state, boot from cold is actually quite a bit 
> slower :(

I'm not sure how much we can improve there. I mean loading those files is
done by katepart, we "just" create Kate::Document nowadays, not even a view
AFAIK. Of course one could also drop creating Kate::Document until one of
the access functions that needs it is actually called, which would mean
only the first file would be loaded and all others would be placeholders.
I'm just not sure wether we'll really gain something with that, or wether
there are plugins/frameworks that access a file directly after loading, for
example for updating the duchain information...

Andreas

-- 
You will receive a legacy which will place you above want.




More information about the KDevelop-devel mailing list