Document loading in kdevelop4

Hamish Rodda rodda at
Thu Jul 27 02:39:11 UTC 2006

On Sunday 23 July 2006 08:26, Adam Treat wrote:
> Hi all,
> As some of you know, from the recent dust-up on kde-commits, the katepart
> now has lazy loading.  This is boon, since it simplifies our code and makes
> document loading faster.  So, I hooked up the documentcontroller to take
> advantage of this lazy loading... and opening a document was indeed, much
> faster.  Still, opening every source file in trunk/KDE/kdevelop takes a
> couple of minutes :(  I believe this is the cost of factory loading of so
> many KParts.
> I don't think this is acceptable.  When a project loads, it should open
> within a minute no matter how large the project or the number of open
> documents.
> I would like to experiment with phony loading of open documents during
> project start-up.  The idea would be the documentcontroller machinery would
> fake load documents at startup and present these to the documentview part. 
> No KPart would actually be created until the user made the document active
> by giving it focus.  Then the part would be created and shown.  The
> drawback is it might take a split second for the document to get focus this
> first time.  Not sure how noticeable it will be.

Previously (when view creation was lazy) there was a delay on first switch to 
a document in creating the view anyway.  However, this can be made less 
noticable (see below).

> Then the document loading on project startup would be limited only by the
> speed of the background parser.
> Thoughts?

I'd like to see preloading of open documents to the left + right of the 
current document (if they're not already loaded), plus possibly preloading of 
the corresponding header/source file (if it is "open" in kdevelop already).  
This would eliminate most of the delay as is at the moment.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the KDevelop-devel mailing list