slow querying

[Seif Lotfy]

My DB has exactly 416 subjects

*** events: 416 time: 0.541239023209
*** events: 1 time: 0.0319149494171 # querying mostused events where subject.uri is a specific uri
*** events: 2 time: 0.499359130859 # querying mostused events where subject.uri is one of 2 specific uris
*** events: 30 time: 10.8581418991 # querying mostused events where subject.uri is one of 30 specific uris
--------------------------------------------

I duplicated the queries again...

*** events: 416 time: 0.487861871719
*** events: 1 time: 0.0361568927765
*** events: 2 time: 0.499109983444
*** events: 30 time: 16.0003550053

What is happening in the background is that i query tracker for a string i get all matching uris and then query Zeitgeist

you can test with lp:~seif/sezen/sezen2/
You will need ZG trunk to test it

[Mikkel Kamstrup Erlandsen (kamstrup)]

I really don't think this classifies as a valid bug report if I understand what you are saying correctly..? You complain that round tripping Client -> Tracker - > Client -> Zeitgeist -> Client is slow?

I think we can only care about the speed of pure Client <-> Zeitgeist interactions. Can you post a simple Python script that illustrates the problems in a purely ZG related scope? Or at the very least you need to profile each of these interactions so we can have an idea where the "bug" is...

[Seif Lotfy (seif)]

No no no i am just showing the Zeitgeist part :)
i am printing the zeitgeist time not tracker time.

On Thu, May 20, 2010 at 8:40 AM, Mikkel Kamstrup Erlandsen <
<email address hidden>> wrote:

> I really don't think this classifies as a valid bug report if I
> understand what you are saying correctly..? You complain that round
> tripping Client -> Tracker - > Client -> Zeitgeist -> Client is slow?
>
> I think we can only care about the speed of pure Client <-> Zeitgeist
> interactions. Can you post a simple Python script that illustrates the
> problems in a purely ZG related scope? Or at the very least you need to
> profile each of these interactions so we can have an idea where the
> "bug" is...
>
> --
> slow querying
> https://bugs.launchpad.net/bugs/583065
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Zeitgeist Framework: Confirmed
>
> Bug description:
> My DB has exactly 416 subjects
>
> *** events: 416 time: 0.541239023209
> *** events: 1 time: 0.0319149494171 # querying mostused
> events where subject.uri is a specific uri
> *** events: 2 time: 0.499359130859 # querying
> mostused events where subject.uri is one of 2 specific uris
> *** events: 30 time: 10.8581418991 # querying
> mostused events where subject.uri is one of 30 specific uris
> --------------------------------------------
>
> I duplicated the queries again...
>
> *** events: 416 time: 0.487861871719
> *** events: 1 time: 0.0361568927765
> *** events: 2 time: 0.499109983444
> *** events: 30 time: 16.0003550053
>
> What is happening in the background is that i query tracker for a string i
> get all matching uris and then query Zeitgeist
>
> you can test with lp:~seif/sezen/sezen2/
> You will need ZG trunk to test it
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/zeitgeist/+bug/583065/+subscribe
>
>

--
This is me doing some advertisement for my blog http://seilo.geekyogre.com

[Seif Lotfy (seif)]

So basically the time resembles

Client -> Tracker - > Client (start timing) -> Zeitgeist -> Client (stop timing)

[Mikkel Kamstrup Erlandsen (kamstrup)]

So ok, what you are really complaining about is the speed of FindEvents/FindEventIds when you pass in a range of templates only with their event.ids set, or are we talking event.subjects[0].uri?

[Seif Lotfy (seif)]

let me post the code:

def search_zeitgeist(self, uris, search_callback, use_objs=True):

t = time.time()
 def _handle_find_events(events):
print "*** events:", len(events)," time: ", time.time() - t
search_callback(events)
 events = []
for uri in uris:
subject = Subject.new_for_values(uri=uri)
event = Event.new_for_values(subjects=[subject])
events.append(event)
self.zg.find_events_for_templates(events, _handle_find_events,
TimeRange.until_now(), num_events=0 , result_type=4)

you can see i am setting specific uris...

On Thu, May 20, 2010 at 11:42 AM, Mikkel Kamstrup Erlandsen <
<email address hidden>> wrote:

> So ok, what you are really complaining about is the speed of
> FindEvents/FindEventIds when you pass in a range of templates only with
> their event.ids set, or are we talking event.subjects[0].uri?
>
> --
> slow querying
> https://bugs.launchpad.net/bugs/583065
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Zeitgeist Framework: Confirmed
>
> Bug description:
> My DB has exactly 416 subjects
>
> *** events: 416 time: 0.541239023209
> *** events: 1 time: 0.0319149494171 # querying mostused
> events where subject.uri is a specific uri
> *** events: 2 time: 0.499359130859 # querying
> mostused events where subject.uri is one of 2 specific uris
> *** events: 30 time: 10.8581418991 # querying
> mostused events where subject.uri is one of 30 specific uris
> --------------------------------------------
>
> I duplicated the queries again...
>
> *** events: 416 time: 0.487861871719
> *** events: 1 time: 0.0361568927765
> *** events: 2 time: 0.499109983444
> *** events: 30 time: 16.0003550053
>
> What is happening in the background is that i query tracker for a string i
> get all matching uris and then query Zeitgeist
>
> you can test with lp:~seif/sezen/sezen2/
> You will need ZG trunk to test it
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/zeitgeist/+bug/583065/+subscribe
>
>

--
This is me doing some advertisement for my blog http://seilo.geekyogre.com

[Markus Korn (thekorn)]

I think we agreed that this is most likely not an issue with zeitgeist, we also changed test/scalability-test.py trying to reproduce exactly this scenario, but the timings provided there are much lower than the timings provided here.
We agreed that this is most likely an issue in sezen's gtk event handling loop.