Note: A container does have "real" work to do and a call to a local bean will be expected to be slower than a normal call. But there are many optimizations and configurable options that reduce the hit. In terms of the actual overhead:

• Marshalling: Unless you specify -DEJBCopyArgs, there is none for intra-bean in-process calls.
• Corba invocation: There is only one ORB for a set of in-process beans. Visibroker is optimized to handle in-process calls much more efficiently than remote calls. Hence there is no overhead for intra-VM bean invocations.
• Transactions: Make sure only a single transaction is started per RPC, if possible. Make sure your access to the in-process beans are not starting their own transactions. Typically, all your beans should have transaction-mode "Required". This mode causes a) a transaction to begin when the call first enters the container, and b) the same transaction to be reused by all calls made within the container. Typically, this is what you want because, if each access to your entity beans occurs in a new transaction, you need to load in the state of the bean for each call. However, if you run all the accesses in a single transaction, you go from thousands of JDBC calls to one or two.
• Security: Unless you have specified security, no ACL is being done.
• Reflection: This is not an issue, since the Container is designed to do all reflection at initialization time only.

You can use the EJBTimers or EJBDetailTimers flags to see exactly what is happening in the container.