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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list