[XESAM] Spec update proposals

[Jos van den Oever]

2007/6/17, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> 2007/6/17, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
>
> > 2007/6/16, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> >
> > > Hi all,
> > >
> > > While hacking on xesam-tools[1] I have struck a few problems in the
> current spec and I think we should settle them asap.
> > >
> > > Please have a look at
> http://wiki.freedesktop.org/wiki/XesamSearchUpdates
> and gimme some feedback.
> >
> >
> > It was just pointed out to me that the query schema in the current form
> does not have extendedSelectionTypes in the selectionTypes - this makes
> regExp and proximity selectors not allowed by the schema. I've updated
> http://wiki.freedesktop.org/wiki/XesamSearchUpdates
>  with a proposal 5.
>
>
> More proposed updates. I've added a point 6 to the list at
> http://wiki.freedesktop.org/wiki/XesamSearchUpdates
> . It has to do with an inherent race condition in the
> search  interface. When you fire a search via NewSearch the server might
> start firing HitsAdded signals before you have a chance to connect to them -
> in fact it might start firing these signals before the call to NewSearch
> returns! I think this is an optimization we need.
>
> The proposed solution is to add a StartSearch() method to the interface.
How about using the query as the search key? The query is rarely very
large and i do not think it will cause much overhead. In fact, i
measured it.
Here are the results of running 10000 dbus queries with a string as
argument. The server is c++, the caller is python.
querylength    time

query length  time
10            2.980s
30            2.971s
100           2.995s
300           3.032s
1000          3.127s
3000          3.364s
10000         4.508s
30000         7.732s

As you can see, the time stays about constant until the query becomes
longer than 1000 characters. At 3000 characters we see 10% loss in
speed. 3000 characters of query is huge. Still only at about 20.000
characters does the dbus performance halve. Using StartQuery() always
halves the dbus performance!

Using the query as key is a bit slower for huge queries. It takes a
bit more memory on the server, but in general it will be faster and
most importantly will be simpler for the user.

It's unintuitive for us hackers to do this in such a simple way,
because it feels like wasting resources. But in fact this is the most
efficient solution.

Cheers,
Jos