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 <[email protected]> wrote: > > > On Fri, Mar 9, 2012 at 1:39 AM, Ignacio Serantes <[email protected]> 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 >> [email protected] >> https://mail.kde.org/mailman/listinfo/nepomuk >> >> > -- Best wishes, Ignacio
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
