[Nepomuk] Performance issues in KDE 4.8.1

[Ignacio Serantes]

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.

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

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20120309/0c96fbba/attachment.html>