[patch] Thread import project

[Andreas Pakulat]

On 31.08.08 15:46:35, Manuel Breugelmans wrote:
> 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?

A long time ago I did a full release build of everything, but I can't
recall whether it was much faster.

> [I haven't] There's a lot of kDebug 
> in there .. might make a difference when those aren't compiled in, dunno.

Well, you can already disable printing it via kdebugdialog, which means
that its "just" the function calls to bring the strings to the
textstream.

I just wanted to valgrind it, but as you can see from the other mail
thats currently impossible.

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

You could just directly connect the finish-signal to the deleteLater
slot when you create the watcher. 

Andreas

-- 
An avocado-tone refrigerator would look good on your resume.