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