qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RFC 1/7] qom: allow properties to be registered


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH RFC 1/7] qom: allow properties to be registered against classes
Date: Thu, 3 Sep 2015 16:49:52 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Sep 02, 2015 at 06:18:28PM +0200, Andreas Färber wrote:
> Am 26.08.2015 um 14:03 schrieb Daniel P. Berrange:
> > When there are many instances of a given class, registering
> > properties against the instance is wasteful of resources. The
> > majority of objects have a statically defined list of possible
> > properties, so most of the properties are easily registerable
> > against the class. Only those properties which are conditionally
> > registered at runtime need be recorded against the klass.
> > 
> > Registering properties against classes also makes it possible
> > to provide static introspection of QOM - currently introspection
> > is only possible after creating an instance of a class, which
> > severely limits its usefulness.
> > 
> > This impl only supports simple scalar properties. It does not
> > attempt to allow child object / link object properties against
> > the class. There are ways to support those too, but it would
> > make this patch more complicated, so it is left as an exercise
> > for the future.
> > 
> > Signed-off-by: Daniel P. Berrange <address@hidden>
> > ---
> >  include/qom/object.h |  44 ++++++++++
> >  qom/object.c         | 233 
> > +++++++++++++++++++++++++++++++++++++++++++++++++--
> >  2 files changed, 270 insertions(+), 7 deletions(-)
> > 
> > diff --git a/include/qom/object.h b/include/qom/object.h
> > index 807978e..068162e 100644
> > --- a/include/qom/object.h
> > +++ b/include/qom/object.h
> > @@ -383,6 +383,8 @@ struct ObjectClass
> >      const char *class_cast_cache[OBJECT_CLASS_CAST_CACHE];
> >  
> >      ObjectUnparent *unparent;
> > +
> > +    QTAILQ_HEAD(, ObjectProperty) properties;
> >  };
> >  
> >  /**
> [snip]
> 
> I had suggested exactly this looong time ago, but Anthony opposed it. I
> don't quite remember why...

It is a while back now so I don't remember all aspects of the discussion
either. The main thing I remember is that we could not simply use the
existing GObject model from glib, since that exclusively records properties
against the object class. In some cases, particularly the relationships
between objects, QEMU needed to be able to define properties on the fly
against object instances.

So that was a definite reason Anthony wanted to have the ability to have
properties against object instances. I don't remember reading anything
about *not* also having the option to define properties against the
object classes. So hopefully this proposal gets us the best of both
worlds - the flexibility of allowing per-instance properties when
needed, along with the reduced memory usage & static introspection
benefits of per-class properties where possible.

> Did you do any benchmarks on performance impact?

I've not done any measurements of impact on CPU time or memory usage.
As mentioned in the intro, I'd expect memory usage to decline significantly
in the case where there are many instances of the same class. Attribute
getter/setters probably have a small CPU hit, due to the need to consult
the linked lists in both the class and object structs. I think that will
be small overall though, and if it is a problem we would probably better
off switching in a hashtable in place of the linked list, so we have
O(1) lookup instead of O(n) lookups.

That all said, I'll try to create a test program to measure these
effects to get some clear numbers to consider.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]