I used to implement a high-speed ORB, that was faster than OmniORB. However, comapring this ORB (or OmniORB for that matter) with TAO or Ice is comparing apples with oranges.
You can get latency down drastically if you choose simpler concurrency models. For example, if you use a blocking client-side concurrency model, latency *will* go down. However, the drawback is that you cannot do nested method calls.
Similarily, there are server-side thread models that are faster than our leader-follower thread pool model, for example "thread per connection". As far as I know, OmniORB uses a blocking client-side concurrency model, and thread-per-connection as server-side concurrency model. (At least that used to be true in the past, I didn't follow the OmniORB development closely.)
So if you compare performance, in particular latency, you must make sure that you have comparable concurrency models. Everything else is comparing apples with oranges.
As for the difference between TAO and Ice, there are two main reasons:
- First of all, we didn't optimize some marshalling code in Ice 1.0 and Ice 1.1. This code is much better optimized in the upcoming 1.2. So expect better performance numbers in 1.2.
- The test was done using different concurrency models. We could easily add a blocking client-side model, which would make a big difference, just to look better in performance tests. However, since such a model is of limited use, we rather don't want to do this.