Threadsafe project model

Milian Wolff mail at milianw.de
Thu Jul 15 22:22:15 UTC 2010


Andreas Pakulat, 16.07.2010:
> 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).

I've also thought that would be the case. Good that you could proof it.

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

Heh, but "Not all that often" is still enough for crashes, no?
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100716/cb7594a6/attachment.sig>


More information about the KDevelop-devel mailing list