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 <berra...@redhat.com> > > --- > > 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 :|
