[patch] Thread import project

[Manuel Breugelmans]

On Sunday 31 August 2008 15:19:03 Andreas Pakulat wrote:
> On 31.08.08 11:59:23, Manuel Breugelmans wrote:
> > The current importing does cut it for me, my GUI either freezes or
> > becomes unresponsive. I've moved the importing to a seperate thread, this
> > does not only keeps the GUI crispy it also gives me a considerable
> > performance boost.
> >
> > With the current import KDevPlatform takes ~10 seconds, with this it
> > loads in about 4 for me [maybe it was the c++ parser that caused these
> > 10s, as it seems a little much]. I've been running with something like
> > this for a couple of days and didnt notice any regressions.
> >
> > Is that sender()->deleteLater() sane? It seems a little fishy ...
>
> I know you can't know this, but we actually already had a threaded
> implementation - about a year ago. Didn't work out at all back then.
> Though IIRC we ran into problems pretty fast, so if you haven't found
> any yet we might have it done right this time around :) So we decided to
> make the import asynchronous only if we really need that - I'd say with
> the slowness of the cmake parser that need exists now. Though I'd find
> it cool to actually be able to valgrind it a bit to see wether we can
> improve the parser somehow.

Has anyone tried it in release mode yet? [I haven't] There's a lot of kDebug 
in there .. might make a difference when those aren't compiled in, dunno.

> More thoughts from me on project-open, especially on buildsystems like
> cmake, qmake and other complex ones which will want to use DUChain:
>
> - have a single point of opening the project, i.e. don't call parse()
>   but let import() do everything (method renaming needed here anyway)
> - use the language parsing framework to do the actual parsing and then
>   use the DUChain information to populate the project tree.
>
> > Index: project/CMakeLists.txt
> > ===================================================================
> > --- project/CMakeLists.txt	(revision 855139)
> > +++ project/CMakeLists.txt	(working copy)
> > @@ -4,7 +4,6 @@
> >  set(kdevplatformproject_LIB_SRCS
> >      projectmodel.cpp
> >      projectconfigskeleton.cpp
> > -    importprojectjob.cpp
>
> Why is the job removed? Having a KJob for opening a project - especially
> when its done in the background allows us to easily have "busy" display
> in the GUI and also enables us to simply kill such an opening-job.

Right, I just found out that QtConcurrent::run can't be canceled, so I guess 
it's a no-go.

> > -    void importDone( KJob* )
> > -    {
> > -       
> > Core::self()->projectControllerInternal()->projectImportingFinished(
> > project ); +void Project::importDone()
> > +{
> > +    Core::self()->projectControllerInternal()->projectImportingFinished(
> > d->project ); +    if (sender()) {
> > +        sender()->deleteLater(); // get rid of the QFutureWatcher
> >      }
> > -};
> > +}
>
> Why is the method moved to Project? It should stay in the Private class.

sender() wouldn't compile if placed in the private class, since it's not a 
QObject.  Maybe project->sender() does the right thing, I haven't tried.


Manuel