[patch] Thread import project

[Andreas Pakulat]

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. 

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.

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

Other than that I don't have any objections against doing this as a
start.

Andreas

-- 
You will inherit millions of dollars.