Re: bonobo-activation cache ...

[Maciej Stachowiak <mjs noisehavoc org>]

On 19Dec2001 06:27AM (-0500), Michael Meeks wrote:
> 
> 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.

So it sounds like in theory it might shave off 8 * 20 * 4 = 640ms,
which would be a great improvement. Any chance you could measure
nautilus startup time with and without the change? Over half a
second's difference should be easy to observe or measure with strace
or the like.

> > 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.

It would be great if we could upgrade running components and programs
in place, but that is impractical. Still, I know this was a huge
problem, one that majorly slowed down nautilus development and
testing, before I made oafd pick up new .server files
automatically. So I think this cache feature is needed.
 
> > 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.

Fixing remaining race conditions is more important, then this problem,
since it causes a potential process leak. As for when I plan to
implement it, that depends on when I have time, since my work on GNOME
is strictly in my own spare time.

> 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 ].

No, what I meant was, if clients must register with the server to know
when to flush the cache, the server can't quit so long as any clients
are registered (unless we add a way for it to tell them it is doing
so.
 
> 	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.

Then the startup time will have to be optimized, won't it? Further, if
the required period of inactivity is long enough, this is unlikely to
come up very often.
 
> 	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.

The purpose of this change is not memory optimization, but rather to
ensure that we don't leak the bonobo-activation-server process. The
other alternative is to kill it on logout, but this is incompatible
with having multiple simulataneous logins on one machine. So this
feature is essential to avoid process leaks correctly. I'm sure I've
explained before that it has nothing to do with the memory usage.

> 	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 ].

If measurements confirm the theoretical major performance win of the
cache, I will be glad to accept such a change along with the needed
extra client interface to maintain cache coherency.

Since the IDL interface between the library and the server is private,
this will not constitute an API change so it will not need API change
review.

However, for the sake of future binary compatibility, I ask that you
include a method in this interface for the server to notify clients
that it's exiting, so we won't have to break compat later.

Thanks for your work on this, it will be a boon to mankind if the
speedup ends up being as much as seems possible.

 - Maciej