TORBA introduces extra processing while sending requests to the CosTrading. This implies an overhead. However, in the context of distributed applications, there are two levels in the evaluation of overhead. First, there are remote method invocations which overhead is potentially high. Second, there are local method invocations which overhead is most of the time insignificant compared to remote method one. In the context of TORBA, the overhead is introduced by the use of a local library, which means local invocations only : Three local invocations are added for each trading request. Thus, it just increases local processing time and keeps the number of remote method invocations identical, compared to the standard use of the CosTrading. Then, based on early test performed using the ORBacus Trader, the overhead introduced by TORBA is, without any ORB specific optimizations in producing TORBA proxies, less than 5%.
There are few ways to improve performance related to trading using TORBA. First, if the only use of the trader is performed through TORBA, then most of the trader checks (like type checking) can be removed since already performed by the proxies. Thus, the overhead brought up by the proxy would be balanced. Second, proxies could be located close to the trading server and not close to the client. Then, the number of network requests could be optimized, improving global performance. Third, using smart proxies, local to the client, to perform caching of trading results, the global performance could be optimized. Finally, a composition of the three aspects will bring the best results. Points two and three are not incompatible as proxies would be split between the trading server and the client application. Client side proxies would perform caching while server side ones would be dedicated to type checking and network optimization.