[omniORB] Measuring omniorb's footprint. New footprint benchmark.

[Haarek Ryeng]

Memory footprint is the size of the static libraries (it used to be (back in the good old days of OmniORB 2.8) a huge difference if you want dynamic Corba or not). Some linkers might be more clever
than others and remove unused symbols.
Run-time memory allocation is a more subtle thing to meassure since it heavily depends on what features you're using. I guess you're better of with not using dynamic Corba, and using run-time features
with care on embedded platforms. Unless you're well equipped with system resources, that is!

Besides, optimizing code usages between processes should be impossible! The whole idea with processes is that they run with their own private and protected virtual memory area to avoid side effects
between processes.

So, Dan, a comparison of library size (linked addresses for library symbols are vissible in the .map file), and run-time memory consumption in _a_ well defined application (utilizing a set of
features) across some of the ORB's and platforms mentioned in your link would be interesting.

- Haarek -


Duncan Grisby wrote:

> On Thursday 21 February, Dan Kegel wrote:
>
> > The benchmark measures how long it takes to do a parallel echo
> > (i.e.
> >   for all servers do
> >      invoke_deferred echo request
> >   for all servers do
> >      collect results )
> > as a function of the number of echo servers running on the
> > computer (both the client and all servers are running locally).
>
> Perhaps I'm being dim, but I don't see how this benchmark measures
> anything to do with footprint at all. You are measuring how well
> send_deferred() works.
>
> In omniORB, send_deferred() doesn't scale very well at all, since it
> creates a new thread for each deferred request. Almost all the latency
> you are seeing will be in thread switching. Improving deferred sends
> might be a nice thing to do in a future omniORB version, but there has
> never been any demand for it.
>
> Your pipe based server also has the huge advantage that the pipes are
> already opened before you do the "calls". omniORB opens a connection
> to the server on the first invocation. If you do a call to each server
> before the calls that you time, you'll find it goes quite a lot
> faster, since the TCP connections will already be open.
>
> Anyway, all of this performance stuff is interesting, but it has
> absolutely nothing to do with memory footprint.
>
> Cheers,
>
> Duncan.
>
> --
>  -- Duncan Grisby  \  Research Engineer  --
>   -- AT&T Laboratories Cambridge          --
>    -- http://www.uk.research.att.com/~dpg1 --

--
Haarek Ryeng
Senior Software Development Engineer
Data Respons AS, Sandviksvn. 26,N-1323 HOEVIK, Norway.
Tel: +47 67112071 Mob: +47 90196734

   Embedded Computers & Realtime Professionals
             www.datarespons.no