[omniORB] Performance Question

[Dietmar May]

Sai-Lai,

> We take performance seriously. I think it bears out in our own test and in
> all the other tests I've seen on the Web that omniORB2 is among the fastest
> ORBs available. The point I was trying to made, perhaps not as clearly as
> it should be, is that there are other aspects to an ORB design that can
> affect the scaling of an ORB's performance.

And quite frankly, we think you've all done an excellent job here ... with just 
a hole or two. It just happens to be in an area that might affect our 
customers.

> Shared memory for obvious reasons could be faster than a loop back socket
> interface. (Is there shared memory support on windows?)

>From MS SDK docs:

"File mapping enables a process to treat the contents of a file as if they were 
a block of memory in the process's address space. The process can use simple 
pointer operations to examine and modify the contents of the file. When two or 
more processes access the same file mapping, each process receives a pointer to 
memory in its own address space that it can use to read or modify the contents 
of the file. The processes must use a synchronization object, such as a 
semaphore, to prevent data corruption in a multitasking environment.

"You can use a special case of file mapping to provide named shared memory 
between processes. If you specify the system swapping file when creating a 
file-mapping object, the file-mapping object is treated as a shared memory 
block. Other processes can access the same block of memory by opening the same 
file-mapping object.

"File mapping is quite efficient and also provides operating-system-supported 
security attributes that can help prevent unauthorized data corruption. File 
mapping can be used only between processes on a local computer; it cannot be 
used over a network."

> The System V shared memory API, which as far as I know, is the API for
> shared memory on all unix platforms is deficient.
> I may also be totally wrong about shared memory, if so please point
> out my mistakes.

I'll take your word for Unix. As far as Win32 is concerned, since shared memory 
is file mapping, the file should be cleaned up when all processes exit.

> I take your point that local bulk data transfer could do better with other
> IPC mechanism. It just isn't something that we have time to look into at
> this time. I assume everybody is happy to see GIOP 1.2, bi-directional GIOP
> for doing callbacks through a firewall, proper codeset conversion support
> for wchar and wstring to come sooner.

That's an answer that I can relate to. (Although none of those are priorities 
for us and our customers :). Perhaps in order to satisfy the needs (or wants) 
of the many, you need to postpone the needs of the few. We'd just like to 
request that the performance issue for local configurations gets looked, and 
not ignored as an unimportant issue.

Perhaps you can answer one or two other questions:

1) Do you know of any easy tweak, perhaps at the socket level, that could be 
tried in a local (same machine) environment to dramatically increase the 
performance? perhaps by bumping buffer size, or by setting some configuration 
flag that bypasses some levels of the socket protocol?

2) If an omniORB server is linked as a Windows DLL, can it be loaded by another 
omniORB server?

If so, are CORBA calls simply executed as virtual function calls (if they are 
both in the same process space)? (I believe that Orbix handles them this way, 
and thought I saw some vague reference to this in omniORB).

Are there any known issues in running this kind of configuration? Is it 
possible for the server to load multiple (different) server DLLs?

Is data in such a configuration transfered without going thru the sockets 
layer? That is, if we have a 4MB sequence, does it get allocated once (by the 
callee) or twice (by the ORB as well). Or in other words, is there the same 
number of copies taking place as if going thru a socket layer?

Regards,
Dietmar