[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] PATCH: Adjust way RPC calls are dispatched in libvirtd



On Fri, Oct 17, 2008 at 12:01:36PM +0100, Richard W.M. Jones wrote:
> On Fri, Oct 17, 2008 at 11:39:40AM +0100, Daniel P. Berrange wrote:
> > Looking at the libvirtd objects with pfunct I knoticed that the method
> > remoteDispatchClientRequest in remote.c was unusually large
> > 
> >   size: 11497, variables: 169, inline expansions: 159 (5144 bytes)
> > 
> > Listing variables present its clear why - for every RPC call, we have 
> > a pair of local variables declared for the structs for the reply and
> > response. Following by a memset() call for every single one.
> > 
> > Any single call to this method only processes one RPC call, so I figured
> > we could collapse all these variables down into a single pair by using
> > a union for all args, and a union for all replies. 
> 
> This all makes sense, but ...
> 
> [...]
> > In doing this I noticed that the dispatch function is O(n) on the 
> > number of RPC calls we have defined. This isn't a serious bottleneck
> > since 'n' isn't very large, but while doing the refactoring for the
> > union stuf, it was easy enough to also change it to declare an array
> > of all the dispatch methods, which could simply be indexed on the 
> > RPC call number. This changes it to O(1) time to dispatch.
> 
> Which part is O(n)?  If you mean the switch statement, then gcc should
> be able to turn this into an array lookup, computed goto or whatever
> is most efficient.

Yeah, I'd hope it would, but it doesn't appear to actually do that
in practice, though I could be mis-reading the asm output.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]