[omniORB] omniNames performance in the list() method

[baileyk@schneider.com]

I'm seeing poor performance in the list() method.  My code is careful to
check for a returned iterator and calls next_n() and destroy() as it
should, but I see that omniNames always returns an iterator even if the
list() call returned all bindings in the context.  As I understand things,
it should be OK to return a nil iterator reference in that case (though I
haven't checked the specs to see if such a thing is required).  Here's a
bit of code I think will do what I want:

   464    lock.readerOut();
   465
   466    // Possible performance patch ---------------------
   467    //
   468    if( all->length() <= how_many )
   469    {
   470       // don't need an iterator.  All results can go back as a
   471       // result of this call
   472       bi = CosNaming::BindingIterator::_nil();
   473       bl = all;
   474       return;
   475    }
   476    // End patch --------------------------------------

This is for NamingContext_i.cc in omniORB v4.0.0.  So just after the lock
is released, if the caller is willing to accept all the bindings, then list
() returns them all ( in the bl out variable ) and sets the iterator (the
bi out variable) to nil.

Is there any reason not to do this?  It saves 2 round trips for a typical
list() call followed by dealing with an iterator pointing to nothing.  I
haven't tested it yet, but I'm pretty sure Orbix 2000 doesn't return an
iterator if list() returns all bindings.  When we switched to omniNames,
some of our application functions which use the name service heavily are
running very slowly.

Kendall