CORBA performance.

[Michael Meeks <michael peabody ximian com>]

On Sun, 2 Dec 2001, Alan Cox wrote:
> Whats the end to end latency of the corba message transfer. Now how
> does that compare to say sunrpc, plan 9, and other saner setups.

	It'd be interesting to measure; for now - no idea.

> It isnt about bandwidth, bandwidth is free. Corba (and bonobo was
> bad at this I dont know if its fixed) is bad at
>
> o Message parsing performance (hard to parse at raw memory speed)

	In ORBit2 message parsing is now slightly slower since it's
all done generical, however the code footprint of the code that does
it is far far smaller which might give some Icache improvement. There
are some trivial optimizations in the pipeline to accelerate the
parsing.

> o Message validation complexity (hard to be secure)

	There is a substantial chunk of code to do this in ORBit2
sadly a load of the GIOP raw message handling code seems to be cut and
paste idl-compiler output instead of generic code; this can be changed
internally leaving us only the (relatively small) generic demarshaller
to audit. I have hopes that this might be feasible someday. In the
meantime, restricting incoming data to that from SSL authenticated
connections sounds reasonable.

> o Number of round trips (latency problem)

	I don't believe CORBA has any particularly unique roundtrip
issues that other RPCs don't - but it's down to interface design a
fair bit - clearly - if you implement a 'getByte' method you're going
to have issues :-)

> o Inability to parallelise well (can't hide latency on parallel
> invocations)

	Hmm; well you can do oneway calls which allow you to dispatch
in a non-blocking fashion, you can also fairly easily create async
stubs / skels that allow a larger degree of non-blocking-ness (
although currently low level writes are synchronous which blows - but
is convenient and fast for memory allocation in many cases ).

> Think about a 10 by 10 spreadsheet containing remotely invoked
> objects in each cell. Latency is your big enemy and unlike bandwidth
> Einstein says you can't have any improvement.

	Sure - and that's why you need a chunky approach to component
development. Ideally, the 10x10 spreadsheet is rendered in a block by
a single process talking to the X server in the same way the app
itself is.

	Be interested in some benchmarks though - they often stimulate
hacking effort all round :-)

		Michael.

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

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers