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 :|