Re: bonobo-activation cache ...

[Michael Meeks <michael ximian com>]

Hello Maciej,

On Tue, 18 Dec 2001, Maciej Stachowiak wrote:
> 1) Have you measured the performance improvement from this change? If
> it's very small it may not be worth coming up with a solution for
> issue 2 below:

	The performance gain is not insiginificant; timing the typical
nautilus query we execute in the patch I sent you, we see ~ 10ms / query
with no cache, and ~2ms / query with it. ie. a 5 fold speedup, not to
mention reduced CORBA traffic, reduced blocking / daemon contention,
reduced context switching, etc. etc. Since we do many of these > 20 times
comprising perhaps 3-4 different queries on startup in Nautilus, it seems
to me to be an optimization worth making.

> 2) The cache needs to be invalidated when new .server files are
> installed. bonobo-activation-server picks these up automatically, and
> before we added this feature, people got horribly confused by the fact
> that new or updated components would not show up.

	Interesting - do they still get confused when their server is left
running in the background while they upgrade and they get the old server -
rather than the new one that they have just installed ? perhaps they
installed 3 new components, and since one was still running they only get
2 new and 1 old etc.

> If we add a client side cache, clients will need to flush the cache
> whenever the server does. A pity because clients haven't needed to
> register with the server before, and this will make it harder to add
> the feature where bonobo-activation-server quits after a period of
> inactivity.

	Firetly, I don't believe it makes it much harder really.
Secondly I'd be curious to know when you plan to implement this feature,
and where it ranks in importance against the other known problems in
bonobo-activation. Either way - I see no reason why this cache should
cause any particular problems whatsoever:

	If you make the server sleep, you need some way of serializing the
state, such as IORs of running objects etc. You simply add a set of
timestamps here as well [ so you can check for newly installed .server
files when you re-activate ].

	Before we check the cache, we simply fetch the activation server
reference - which if asleep must cause re-activation of the server [ which
will notify us of any changes in the dataset ].  Thus it is not difficult
to implement the sleeping feature with this cache; that is if server sleep
were to be implemented.

	As regards the advisability of such a feature; I tend to feel it
would create an ergonomic nightmare, it takes worse than 1sec. to start
bonobo-activation-server on my machine - and for the user to see this sort
of latency opening a new nautilus window, or even changing directory after
reading a document seems crazy to me.

	Yes bonobo-activation-server consumes 1Mb - it would be good to
get that out of memory, but lots of this is translated strings that chew
bandwidth in queries, and waste space in core. Surely it would be more
effective to spend some time adding more locale intelligence to the
client/daemon than adding a large delay for the user.

	Anyhow - can you confirm that you would be happy to add a client
interface ? I'm happy to do it, but I'd perfer to know that it would be
accepted first. If / when you do a server sleep mode I'd be most happy to
add the few lines to ensure cache consistancy at the client - indeed, I
hope we can cache much more at the client in due course such as certain
activation results [ this will need more work though ].

	Awaiting your reply,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot