KDevelop: General direction and UI - don't worry

Hamish Rodda rodda at kde.org
Fri Nov 7 00:56:49 UTC 2008


On Wednesday 05 November 2008 20:43:55 Andreas Pakulat wrote:
> 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.

That was the plan with sublime, but the reality is different... I'm hoping 
Alex's work fixes this issue too.

> 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...

There's a trade off between speed while starting up and speed while running 
here, if we try to switch to an "open" file which still needs to be loaded 
from disk it will be unacceptably slow to display.

Cheers,
Hamish.




More information about the KDevelop-devel mailing list