Threadsafe project model

[Andreas Pakulat]

Hi,

I experimented today with the threadsafe project model idea (well,
actually just thread-safe project items for now). I've pushed the branch
into the kdevelop-developers clone of kdevplatform. I was mostly
interested in how much performance is hit when using locks for
read/write access to the item data and the result is rather
discouraging. I've uploaded the callgrinds to 
http://apaku.de/vardata/callgrind.out.14970.master.zip
http://apaku.de/vardata/callgrind.out.15234.lock_for_project.zip

What I did was simply starting the projectmodelperformancetest
app, click expandall and while it was computing close the app (but don't
let kwin kill it). As is visible the lock-functions make up a
significant amount of time compared to the rest of the project item
functions (except the fileitem constructor which is due to the 1000 or
so items being created at startup).

I've also done a non-scientific test of doing the same while running the
test through "time" and this showed a 30% difference (6.1 for locking
vs 4.3 seconds for master).

So I guess making the model or items threadsafe is not an option at this
point. Instead we'll have to make sure that all changes to it are being
done through the UI thread (not sure wether the gui-lock would help
here).

Instead of the patch that Aleix posted a few days ago I'd like to factor
this into a more general job-like class which can be given some code
or function to run it queued in the gui thread. This might be useful in
other cases too... Then all code that accesses the model in a writing
way (i.e. that causes gui updates) would use this instead of having a
hardcoded-to-projectmodel solution. 

That would still leave problems for accessing the model in reading ways,
but I guess that doesn't result in races all that often...

Andreas

-- 
Your business will go through a period of considerable expansion.