Re: libvirt statistics

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

 



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

Attachment: pgp1IKRWKKQ07.pgp
Description: PGP signature

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]