[Libvir] libvirt statistics
[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_data5648 8 remote_domain_get_info_ret 4032 8 XDR 4840 8 xen_v0_vcpuinfo 4032 8 _xmlValidCtxt 112 104 8 _xmlEntity 136 128 8 _xmlParserCtxt 696 67224 _testConn14504 14496 8 _xmlURI 8072 8 _xmlXPathObject 725616 _xmlXPathParserContext 8072 8 _xmlXPathContext 352 33616 _xmlError 8880 8 _xmlAttr9688 8 _xmlDoc168 160 8 _xmlNode 120 112 8 _IO_FILE 216 208 8 _virDomainInfo 4032 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):
Re: [Libvir] libvirt statistics
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 67224 _testConn14504 14496 8 _xmlURI 8072 8 _xmlXPathObject 725616 _xmlXPathParserContext 8072 8 _xmlXPathContext 352 33616 _xmlError 8880 8 _xmlAttr9688 8 _xmlDoc168 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 xenUnifiedDriverxenDaemonDriver; /* 1 */ struct xenUnifiedDriverxenHypervisorDriver; /* 1 */ struct xenUnifiedDriverxenProxyDriver; /* 1 */ struct xenUnifiedDriverxenStoreDriver; /* 1 */ struct xenUnifiedDriverxenXMDriver; /* 1 */ Those seem to work like class definitions, so they are not a Bad Thing, too. extern xmlFreeFuncxmlFree; /* 3 */ extern xmlMallocFunc xmlMalloc; /* 0 */ Not from libvirt code. -- Eduardo pgpZaw5ww4LAw.pgp Description: PGP signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] libvirt statistics
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 -=| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] libvirt statistics
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 67224 _testConn14504 14496 8 _xmlURI 8072 8 _xmlXPathObject 725616 _xmlXPathParserContext 8072 8 _xmlXPathContext 352 33616 _xmlError 8880 8 _xmlAttr9688 8 _xmlDoc168 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 smime.p7s Description: S/MIME Cryptographic Signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
