[Nepomuk] Performance issues in KDE 4.8.1

[Vishesh Handa]

On Fri, Mar 9, 2012 at 1:25 PM, Ignacio Serantes <kde at aynoa.net> wrote:

> Hi,
>
> I'm not sure but seems like creating a resource with Nepomuk.Resource() is
> slow than before and needs more CPU. This is a point that probably Ehrichs
> could confirm better than me.
>

Yup. It should be slower, we're now doing error checking. I'm not sure
about it needing more CPU than before, though.

An about the synchronous has it's advantages where there is a sort in
> client side, there is a lot of resources, you are handling correctly the
> fetch on demand and you are connecting to an internet server but, if  there
> is performance issues returning 144 records from a local database server
> because the operation is synchronous, I think we have a little problem. In
> fact with so few records probably asynchronous operation will be slow in
> total time ;).
>

Uhh. I lost you. Isn't 144 records a lot?

What happens with the synchronous version is -

1. One blocking query to get all the resource uris of type nao:Tag
2. One query for each nao:Tag in order to load *all* of its properties, and
then store them in a cache.

Considering that we do not need all of the properties and we only require a
label. One query would be a lot better, even if it is synchronous.


>
> How many queries are required to create a resource? Is cache working as
> expected? I know there is a cache because I have issues, expected cache
> issues :), developing nepoogle so it's still working as expected? Obviously
> there is something different in the last version of KDE.
>

What kind of cache issues are you experiencing? Cause with 4.8.1 we have
added extra code to make sure that the cache is always up to date.


>
> On Fri, Mar 9, 2012 at 6:52 AM, Vishesh Handa <me at vhanda.in> wrote:
>
>>
>>
>> On Fri, Mar 9, 2012 at 1:39 AM, Ignacio Serantes <kde at aynoa.net> wrote:
>>
>>> Hi,
>>>
>>> Just installed KDE 4.8.1 I found a severe performance issue with my
>>> plasmoid Drop2TagIcon.
>>>
>>> Some investigation reveals that the problem is the call to
>>> Nepomuk.Tag.allTags() and, as I have 5 Drop2TagIcon in each of my four
>>> activities, the final result is that Plasma was totally frozen.
>>>
>>> Sadly this seems not restricted to Python, in irc Jörg Ehrichs has
>>> similar issues with Conquirere and a few minutes ago, when I'm trying to
>>> tag files using Dolphin in the old fashion way, I discover that the problem
>>> is here too.up
>>>
>>
>> Yup. Nepomuk::Tag::allTags() is synchronous, and ideally, shouldn't be
>> used.
>>
>> I've noticed the performance impact as well.
>>
>>
>>> More information:
>>> - I have only 144 tags.
>>> - Over 7-8 seconds passed between I click in Dolphin "Add Tags..." and
>>> the dialog is displayed.
>>> - Meanwhile over 33% of my dual core CPU is used by the
>>> nepomukservicestub that launches virtuoso.
>>> - The next query:
>>>
>>> SELECT ?uri ?label
>>>
>>> WHERE {
>>>
>>> ?uri rdf:type nao:Tag .
>>>
>>> OPTIONAL { ?uri nao:prefLabel ?label . } .
>>>
>>> } ORDER BY ?label
>>>
>>> took over 150-170 milliseconds using NepSak and consuming 6% for an
>>> instant.
>>>
>>
>> That seems decent. I was going to use the QueryLibrary, but maybe I could
>> directly use sparql.
>>
>>
>>>
>>> --
>>> Best wishes,
>>> Ignacio
>>>
>>>
>>>
>>> _______________________________________________
>>> Nepomuk mailing list
>>> Nepomuk at kde.org
>>> https://mail.kde.org/mailman/listinfo/nepomuk
>>>
>>>
>>
>
>
> --
> Best wishes,
> Ignacio
>
>
>
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20120309/e3857f4a/attachment-0001.html>