>> There is a large perception of CORBA being slow, but for the most part
>> it is unjustified.
> Well, I've measured using function calls through ORBit is 300 times
> slower than using dynamic loading.
> ...
> Which gives me the dl is about 333 times faster than ORBit.
You leave so many details out, and you sortof miss the point with my
statement. The idea is that CORBA doesn't specify a transport to use _at
all_ except when doing inter-orb communication (which you basically have
to use IIOP to be compatible). This is why, for example, if you
ior-decode ORBit IORs that they contain two parts: an IIOP portion, and a
Unix domain socket portion. Basically ORBit is optimizing the
intramachine case, because it is very common for purposes that ORBit is
mainly used: GNOME.
You didn't specify, but I assume that you were using the Unix sockets
transport for your benchmark. I am also assuming that the two things
communicating were in different processes. If you wanted to make a more
fair test case, you would have to use some form of IPC mechanism to
communicate between two distinct processes. Comparing a function call to
an RPC mechanism will never look good. :)
There are many other optimizations that one can make the transport faster
that ORBit doesn't implement. For example, you could mmap (shared) data
buffers between the two processes communicating (of course, you still need
to wake processes up, which is why it hasn't been done yet), or you could
use pipes (if you can control forkness) or any number of things. If you
are communicating with a server in the same process as your client
(because it was dynamically loaded) you can even do a direct function
call.
When I said that "for the most part it is unjustified" to think that CORBA
is slow, what I meant is that CORBA isn't slow: implementations are. Just
look at the difference between ORBit and all those other orbs out
there... orders of magnitude speed differences, with little or no
functionality differences.
What CORBA gives you is the power to have optimizations for important
special cases (in kORBit's case, one of those would be User->kernel),
WITHOUT sacrificing the big picture or the ability to be interoperable...
I am not claiming that kORBit is where it needs to be right now. :)
-Chris
http://www.nondot.org/~sabre/os/
http://www.nondot.org/MagicStats/
http://korbit.sourceforge.net/
On Thu, Dec 14, 2000 at 11:10:24AM -0600, Chris Lattner wrote:
> There are many other optimizations that one can make the transport faster
> that ORBit doesn't implement. For example, you could mmap (shared) data
> buffers between the two processes communicating (of course, you still need
> to wake processes up, which is why it hasn't been done yet), or you could
This is not necessarily faster.
I recently came across some discussions on the web from Jim Gettys that
discussed similar issues for X (unix sockets vs shared memory). I seem to
remember that the over head of synchronizing stuff to keep the shared
memory in a sane state ate away at any gains one had with using shared
memory. It works ok for large chunks of data (say, things on the order of
sizes of pixmaps), but not for smaller pieces, like say, function call
arguments.
Then again, isn't Jim some how involved in ORBit and GNOME? Or just a big
supporter? :->
mrc
--
Mike Castle Life is like a clock: You can work constantly
[email protected] and be right all the time, or not work at all
http://www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
On Thu, Dec 14, 2000 at 03:44:01PM -0600, Mike Castle wrote:
> Then again, isn't Jim some how involved in ORBit and GNOME? Or just a big
> supporter? :->
Jim works on XFree86 (among other things). So yes, he is indeed
*somehow* involved in GNOME ;-)
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/