[omniORB] omniorb and omniorbpy speed

dek_ml@konerding.com dek_ml@konerding.com
Thu, 30 Nov 2000 20:02:00 -0800

Duncan Grisby writes:
>On Thursday 30 November, Michael Lauer wrote:
>> Puuh... this sounds scary... but seriously... I'm developing CORBA
>> applications with Python and omniORBpy and I'm very happy with the
>> speed. Isn't the time spent in Python and in omniORBpy less
>> important in distributed applications because of the network speed
>> penalty ?
>It all depends what you are doing. Clearly if Python is fast enough
>for your application, then speed is not a problem. In a widely
>distributed system, network latency and bandwidth become a factor in
>the application's speed, along with others like design of the
>interfaces, choice of programming language, and choice of algorithms.
>There are no simple answers about whether you should use Python or
>C++. A good option for many applications is to develop things quickly
>using Python, then re-write portions in C++ if they are too slow. In
>most systems, the amount of C++ required would be minimal. Of course
>there are also issues of static typing versus dynamic typing, and all
>that sort of thing.

I should mention that I'm using omniORB (after FNORB proved to be too
slow) for a high performance molecular modelling application, and it's
working great.  We can get real-time interactive modelling which is
synchronized between two workstations, with acceptably small latency.

All the synchronization code is written in python (as is much of the
modelling application- the compute intensive stuff is in C++).  I've been
very impressed with omniORB, especially when compared to FNORB, which had
latencies up to 1 second!  I rarely see latencies of .1 sec with omniORB.