[Accessibility] FSGA Teleconference Agenda, Wednesday 28 June

Michael Meeks michael at ximian.com
Fri Jul 21 03:45:26 PDT 2006

On Wed, 2006-07-12 at 12:01 -0400, Jonathan Blandford wrote:
> > I've seen Frank Duignan's performance analysis work that provides
> > numbers to the effect that DBUS is approximately 18 times slower than
> > CORBA:
> > 
> > http://eleceng.dit.ie/frank/rpc/CORBAGnomeDBUSPerformanceAnalysis.pdf
> > 
> > I'm curious if there's been any response to Frank's work?  I'd be
> > especially interested in what the DBUS developers have to say.  Is the
> > analysis accurate/fair?  Does the testing mechanism correlate to how we
> > use CORBA for the AT-SPI?  Is there low hanging fruit in the DBUS
> > performance tree?  Etc.
> That's a pretty interesting paper.  Is the benchmark code available
> anywhere?  Two immediate thoughts there are:

	It surprised me too - I would have expected it to be only 2-3x slower
(or so) going via the bus. Anything more looks like implementation
sillies, and to be honest no-one has profiled ORBit2 since Elliot left
so long ago, so I'm sure with a little effort D-BUS can do a lot better.

	Having said that - the paper is interesting; the identification of
hashing as the cause of performance issues is not correct - that is only
available for the in-proc case, and not used remotely; instead we have
IDL compiler compiled:

static ORBitSmallSkeleton
get_skel_small_Bonobo_PersistFile(POA_Bonobo_PersistFile *servant,
const char *opname,gpointer *m_data, gpointer *impl)
	switch(opname[0]) {
	case 'g':
		switch (opname[1]) { ...

	type code - which is (I guess) one of those areas I never go around to
de-soptimizing ;-) I imagine a hash would perform only slightly slower,
while using less code size etc. [ cf. eg. Bonobo-skels.c ].

	I imagine the most surprising thing (to me) in this was that I thought
that most of the slowness in IPC should be in the kernel, but perhaps we
should revise that common wisdom [ then again ORBit2 goes to some effort
to construct pleasant looking iovecs, each call should be ~1 'writev',
and we allocate most scratch memory with alloca ].



 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot

More information about the Accessibility mailing list