[XESAM] Spec update proposals

[Arun Raghavan]

Hello,

On 6/23/07, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com> wrote:
> 2007/6/22, Jos van den Oever <jvdoever at gmail.com>:
> > 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.
<snip>

The memory impact will probably not be significant -- just one copy of
the query. The server will probably just have a map of the (string
searchId, SearchObject obj) (well, mine does at any rate), and in most
implementations the map will just use a hash of the string searchId
key.

However, as you say, using the query string does not "feel right". The
cost of using StartSearch() might be double that of not, but from your
numbers it looks like we'll be moving from O(0.3 ms) to O(0.6 ms).
Perhaps that might be an acceptable tradeoff?

A not so great alternative might be to just use a hash of the query as
the searchId (potentially introducing a dependency on some library to
provide a MD5/SHA1 implementation).

<snip>
> Historical Note:
> Using the query string as search handle was in fact one of the first
> proposals for the xesam search spec. I think we better dig out why it
> was rejected then...

Some digging turned up this --
http://article.gmane.org/gmane.comp.freedesktop.xdg/8016. I dug a
little further back too, but that looked too preliminary to cover
this.

Best,
--
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com