Skip navigation.
KDE Developer's Journals

Nepomuk Performance and GUI goodies

trueg's picture

Some words on performance

Nepomuk performance has always been a bit of a problem. Last but not least this was due to the D-Bus communication with the Nepomuk server that took place all the time. Don't get me wrong, D-Bus is pretty fast, but you always get the overhead of the marshalling of messages and routing them through the D-Bus daemon.
So with the new QLocalServer and QLocalSocket in QT 4.4 which introduce Windows compatibility, I re-enabled the Soprano local socket communication which is a lot faster.
Now the Nepomuk server provides two interfaces: the good old and very easy to use D-Bus interface and the fast binary local socket interface. (The latter is barely documented since it is only intended for Soprano itself through Soprano::Client::LocalSocketClient).
To use the new interface one could of course create and instance of LocalSocketClient but that is not recommended for two reasons:

  1. The path to the socket would be hardcoded in the application
  2. The local socket communication does not support signals

That is why libnepomuk provides a fancy Soprano::Model implementation that handles all this transparently. It executes all commands through the socket interface while listening for signals via D-Bus. At the moment this Model can be accessed through

Soprano::Model* mainModel = Nepomuk::ResourceManager::instance()->mainModel();

Internally a new class called Nepomuk::MainModel is used. That one is not public API yet but might become at some point to allow developers to use the interface without creating a ResourceManager instance.
Apart from that I also did some small optimizations in Soprano which I tracked down using valgrind. Very cool, I think that is actually the first time I was able to improve performance based on valgrind results.

GUI stuff

Ok, enough of the internal implementation details. Lets have a look at some nice GUI improvements that I would like feedback on. The target is Dolphin which has been providing Nepomuk annotations for quite a while now. The problem always was that I created ugly prototype widgets which I never improved (except for the rating one). Yesterday evening I changed that and commited a tagcloud and a new commenting widget to Dolphin. Now it still looks a bit cluttered but IMHO much better than before.

Dolphin new tagging

The basic idea for both is to display the comment and the tags read-only and allow the user to edit them in a fancy popup which appears after clicking on the appropriate button. In case of the tagcloud we get another tagcloud which shows all available tags, the ones assigned selected.
Please go ahead and test it and let me know how it can be improved. This does include the look and feel as well as the layout of the sidebar (spacing and margins and alignment and stuff).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
sprouts's picture

tags

Love the developments to the tags. More useable than before. What I'd find really useful, especially for navigating my files at work, is for clicking on a tag, to filter for all files having that tag, allowing you to navigate just using tags. Probably one for later. Anyway, I await all developments of nepomuk avidly, and am impressed by how much it has progressed so far. I think it will revolutionise how I work.

trueg's picture

Tag KIO slave

Then you might check out the Tag KIO slave in playground. It allows you to browse your files based on tags.

richard dale's picture

Tuning D-Bus performance by cutting down message pairs?

I would think the overhead with D-Bus vs QLocalSocket would be latency, rather than data transfer rate, and so reducing the number of calls would be a good way to tune performance. For instance, after a SPARQL query at the moment, the xml reply is converted to Soprano::Nodes in a hash table for each binding in the binding set. To iterate through the set and obtain the next binding, a next() and a current() call is needed. I would think it would be more efficient to just send the whole xml SPARQL reply over D-Bus (up to some limit like 10k) and then handle the iteration on the client side.

For the ruby soprano bindings I used the D-Bus interface directly, and demarshalled in the ruby code, rather than wrap the C++ model layer in a ruby binding. Maybe I shouldn't be using D-Bus directly if I'm missing out on these optimisations. For the Nepomuk mainModel() bindings I'll have a look at whether that would be possible.

I'll add the Nepomuk widgets to the smoke library so they can be used in korundum with Ruby.

trueg's picture

Optimizing D-Bus calls

I thought about that, too. Optimizing the iteration by transferring packs of results rather than just one. Maybe I could add this as an optional way to use the D-Bus interface to stay compatible. Something along the lines of:

QList<BindingSet> getResults( int offset, int max )

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.