[Using `pahole' and friends - see http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git;a=summary and https://ols2006.108.redhat.com/2007/Reprints/melo-Reprint.pdf ] These are all on x86-64. You'll get slightly different results on a 32 bit arch. Largest structures, by size: qemud_vm_def: 16608 4 qemud_vm_os_def: 16436 1 _testConn: 14504 2 qemud_vm: 12368 2 qemud_network: 8240 0 qemud_vm_disk_def: 4376 2 qemud_driver: 4192 1 qemud_vm_net_def: 4136 2 xenXMConfCache: 4112 0 _virProxyFullPacket: 4096 0 _xmlParserCtxt: 696 5 _virDriver: 432 1 utsname: 390 0 _testDom: 360 0 _xmlXPathContext: 352 4 xenUnifiedDriver: 328 0 dirent: 280 0 _xmlSAXHandler: 256 1 _IO_FILE: 216 2 _xenUnifiedPrivate: 192 1 qemud_network_def: 192 2 _xmlDoc: 168 2 _virConnect: 168 0 _testNet: 156 0 Structures with holes which could be made smaller by packaging (third number is how many bytes you'd save per allocation): qemud_vm 12368 12360 8 qemud_vm_def 16608 16600 8 private_data 56 48 8 remote_domain_get_info_ret 40 32 8 XDR 48 40 8 xen_v0_vcpuinfo 40 32 8 _xmlValidCtxt 112 104 8 _xmlEntity 136 128 8 _xmlParserCtxt 696 672 24 _testConn 14504 14496 8 _xmlURI 80 72 8 _xmlXPathObject 72 56 16 _xmlXPathParserContext 80 72 8 _xmlXPathContext 352 336 16 _xmlError 88 80 8 _xmlAttr 96 88 8 _xmlDoc 168 160 8 _xmlNode 120 112 8 _IO_FILE 216 208 8 _virDomainInfo 40 32 8 Longest functions (NB: long functions are not a bad thing -- read Steve McConnell). qemudParseVMDef: 9680 doRemoteOpen: 6631 xenXMParseXMLToConfig: 5678 xenXMDomainFormatXML: 5678 xend_parse_sexp_desc: 5424 qemudBuildCommandLine: 5204 virDomainParseXMLDesc: 3503 qemudGenerateXML: 2556 __virErrorMsg: 2332 testOpenFromFile: 2210 call: 2206 qemudStartNetworkDaemon: 2105 virDomainParseXMLOSDescHVM: 2078 qemudParseNetworkDef: 2023 xenHypervisorMakeCapabilitiesXML: 1838 virDomainParseXMLDiskDesc: 1686 qemudStartVMDaemon: 1683 xenXMConfigCacheRefresh: 1547 xenXMParseXMLDisk: 1545 virConfParseValue: 1516 virConfParse: 1457 qemudScanConfigDir: 1396 testLoadNetwork: 1353 dhcpStartDhcpDaemon: 1259 virXen_getvcpusinfo: 1257 testLoadDomain: 1244 qemudDomainSave: 1194 virDomainParseXMLIfDesc: 1164 xenHypervisorInit: 1104 xenXMDomainDefineXML: 1083 iptablesAddRemoveRule: 1081 testOpen: 1075 Functions with the most variables (perhaps a better indicator of "complexity", I know that doRemoteOpen is a bloody complicated function for example): xenXMDomainFormatXML: 18 virDomainParseXMLDesc: 18 doRemoteOpen: 18 testLoadDomain: 17 xenHypervisorMakeCapabilitiesXML: 16 testLoadNetwork: 15 xenXMParseXMLDisk: 14 xenStoreLookupByName: 13 xend_parse_sexp_desc: 13 virDomainParseXMLDiskDesc: 13 testOpenFromFile: 12 qemudBuildCommandLine: 12 xenStoreDomainGetNetworkID: 10 xenDaemonDomainGetVcpus: 10 virDomainParseXMLOSDescHVM: 10 qemudParseInterfaceXML: 10 xenXMParseXMLVif: 9 xenXMParseXMLToConfig: 9 xenXMDomainDefineXML: 9 query_parse: 9 iptablesAddRemoveRule: 9 xenStoreListDomains: 8 xenHypervisorLookupDomainByUUID: 8 xenHypervisorInit: 8 xenDaemonListDomainsOld: 8 virDomainParseXMLOSDescPV: 8 virDomainParseXMLIfDesc: 8 testNetworkDumpXML: 8 testDomainDumpXML: 8 qemudNetworkIfaceConnect: 8 qemudGenerateXML: 8 qemudDomainSave: 8 Functions with more than one "goto" label: qemudAddIptablesRules: 10 doRemoteOpen: 4 xenDaemonOpen: 3 qemudStartNetworkDaemon: 3 qemudExtractVersionInfo: 3 xenXMDomainFormatXML: 2 xenHypervisorInit: 2 xend_parse_sexp_desc: 2 virParseXMLDevice: 2 __virGetNetwork: 2 __virGetDomain: 2 virDomainXMLDevID: 2 remoteForkDaemon: 2 query_parse: 2 qemudStartup: 2 qemudNetworkIfaceConnect: 2 qemudGenerateXML: 2 qemudBuildCommandLine: 2 negotiate_gnutls_on_connection: 2 Functions with the most parameters (in C these are dangerous because of C's lousy typechecking): __virRaiseError: 12 xenXMConfigSetIntFromXPath: 8 xenUnifiedDomainMigratePrepare: 8 xenDaemonDomainMigratePrepare: 8 __virDomainMigratePrepare: 8 remoteDomainMigratePrepare: 8 qemudReadMonitorOutput: 8 call: 8 xenXMConfigSetStringFromXPath: 7 xenUnifiedDomainMigratePerform: 7 xenDaemonDomainMigratePerform: 7 _virExec: 7 __virDomainMigratePerform: 7 remoteDomainMigratePerform: 7 xenUnifiedDomainMigrateFinish: 6 xend_op_ext2: 6 virXen_getvcpusinfo: 6 virExecNonBlock: 6 virExec: 6 virDomainParseXMLOSDescHVM: 6 __virDomainMigrateFinish: 6 virDomainMigrate: 6 remoteDomainMigrateFinish: 6 All global variables (nothing wrong with global variables, I say): extern unsigned int __invalid_size_argument_for_IOC; /* 0 */ struct qemu_feature_flags arch_info_i686_flags[4]; /* 0 */ struct qemu_feature_flags arch_info_x86_64_flags[3]; /* 0 */ struct qemud_driver * qemu_driver; /* 0 */ struct qemu_arch_info qemudArchs[7]; /* 1 */ extern struct _IO_FILE * stderr; /* 9 */ extern struct _IO_FILE * stdin; /* 23 */ extern struct _IO_FILE * stdout; /* 23 */ enum /**/ virDrvOpenRemoteFlags; /* 0 */ struct xenUnifiedDriver xenDaemonDriver; /* 1 */ struct xenUnifiedDriver xenHypervisorDriver; /* 1 */ struct xenUnifiedDriver xenProxyDriver; /* 1 */ struct xenUnifiedDriver xenStoreDriver; /* 1 */ struct xenUnifiedDriver xenXMDriver; /* 1 */ extern xmlFreeFunc xmlFree; /* 3 */ extern xmlMallocFunc xmlMalloc; /* 0 */ Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Hi, On Thu, Sep 06, 2007 at 02:10:39PM +0100, Richard W.M. Jones wrote:
[Using `pahole' and friends - see http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git;a=summary and https://ols2006.108.redhat.com/2007/Reprints/melo-Reprint.pdf ]
These are all on x86-64. You'll get slightly different results on a 32 bit arch.
Largest structures, by size:
qemud_vm_def: 16608 4 qemud_vm_os_def: 16436 1 _testConn: 14504 2 <snip>
What is the second field here?
Structures with holes which could be made smaller by packaging (third number is how many bytes you'd save per allocation):
<snip>
_xmlValidCtxt 112 104 8 _xmlEntity 136 128 8 _xmlParserCtxt 696 672 24 _testConn 14504 14496 8 _xmlURI 80 72 8 _xmlXPathObject 72 56 16 _xmlXPathParserContext 80 72 8 _xmlXPathContext 352 336 16 _xmlError 88 80 8 _xmlAttr 96 88 8 _xmlDoc 168 160 8 _xmlNode 120 112 8
Are those defined by libxml, or are they from the libvirt code?
Functions with the most parameters (in C these are dangerous because of C's lousy typechecking):
__virRaiseError: 12
12 parameters, wow!
All global variables (nothing wrong with global variables, I say):
extern unsigned int __invalid_size_argument_for_IOC; /* 0 */
Doesn't seem to be from libvirt code.
struct qemu_feature_flags arch_info_i686_flags[4]; /* 0 */ struct qemu_feature_flags arch_info_x86_64_flags[3]; /* 0 */ struct qemud_driver * qemu_driver; /* 0 */ struct qemu_arch_info qemudArchs[7]; /* 1 */
Not many. The arrays smell like constant data, that wouldn't be a Bad Thing being global. Some may be made static, however.
extern struct _IO_FILE * stderr; /* 9 */ extern struct _IO_FILE * stdin; /* 23 */ extern struct _IO_FILE * stdout; /* 23 */
System variables.
enum /**/ virDrvOpenRemoteFlags; /* 0 */
I think this was supposed to be a type definition. The variable is never used.
struct xenUnifiedDriver xenDaemonDriver; /* 1 */ struct xenUnifiedDriver xenHypervisorDriver; /* 1 */ struct xenUnifiedDriver xenProxyDriver; /* 1 */ struct xenUnifiedDriver xenStoreDriver; /* 1 */ struct xenUnifiedDriver xenXMDriver; /* 1 */
Those seem to work like "class" definitions, so they are not a Bad Thing, too.
extern xmlFreeFunc xmlFree; /* 3 */ extern xmlMallocFunc xmlMalloc; /* 0 */
Not from libvirt code. -- Eduardo
Eduardo Habkost wrote:
Hi,
On Thu, Sep 06, 2007 at 02:10:39PM +0100, Richard W.M. Jones wrote:
[Using `pahole' and friends - see http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git;a=summary and https://ols2006.108.redhat.com/2007/Reprints/melo-Reprint.pdf ]
These are all on x86-64. You'll get slightly different results on a 32 bit arch.
Largest structures, by size:
qemud_vm_def: 16608 4 qemud_vm_os_def: 16436 1 _testConn: 14504 2 <snip>
What is the second field here?
Good question! I had to look at the source code and it turns out the the second numeric field is the number of holes.
Structures with holes which could be made smaller by packaging (third number is how many bytes you'd save per allocation):
<snip>
_xmlValidCtxt 112 104 8 _xmlEntity 136 128 8 _xmlParserCtxt 696 672 24 _testConn 14504 14496 8 _xmlURI 80 72 8 _xmlXPathObject 72 56 16 _xmlXPathParserContext 80 72 8 _xmlXPathContext 352 336 16 _xmlError 88 80 8 _xmlAttr 96 88 8 _xmlDoc 168 160 8 _xmlNode 120 112 8
Are those defined by libxml, or are they from the libvirt code?
They're in libxml2. The way that the dwarves programs work is they consider the whole program or shared library, everything it contains and all dependent libraries down to libc.
enum /**/ virDrvOpenRemoteFlags; /* 0 */
I think this was supposed to be a type definition. The variable is never used.
Yes, it's a bug! Patch coming up ... Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Thu, Sep 06, 2007 at 02:10:39PM +0100, Richard W.M. Jones wrote:
[Using `pahole' and friends - see http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git;a=summary and https://ols2006.108.redhat.com/2007/Reprints/melo-Reprint.pdf ]
These are all on x86-64. You'll get slightly different results on a 32 bit arch.
Largest structures, by size:
qemud_vm_def: 16608 4 qemud_vm_os_def: 16436 1 _testConn: 14504 2 qemud_vm: 12368 2 qemud_network: 8240 0 qemud_vm_disk_def: 4376 2 qemud_driver: 4192 1 qemud_vm_net_def: 4136 2 xenXMConfCache: 4112 0
Hmm, practically all of those large structs come from the statically allocated char arrays of PATH_MAX. Switching them to be malloc'd would save far more than packing the structs. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
participants (3)
-
Daniel P. Berrange -
Eduardo Habkost -
Richard W.M. Jones