On Tue, 3 Jun 2008 13:34:13 +0200 Kristian Rietveld <kris imendio com> wrote: > 4. We will completely lose all means to simply access fields by just > dereferencing the structure. Instead, we will start to use GObject > properties to access this data much more often. Using g_object_[sg]et() > can become a little tedious. Therefore we should introduce a couple of > convenience accessors for GObject properties such as g_object_get_int(), > *double(), *string(), etc. Because of the dynamic nature of the GObject property system, this would also bring a substantial performance overhead, eg: - unnecessary dynamic lookup of a pspec whose name and details are known at compile time - unnecessary round-trip through GValue - for non-virtual properties, unnecessary indirect call - unnecessary switch in the global get_property/set_property, as opposed to per-property accessors - ... Have you ever considered switching to a static design? It would eliminate the unnecessary dynamic overhead, and it would also make it much easier to implement a GObject. That is, property declarations would be put into a separate input file, which a simple GObject compiler would use to generate the relevant C glue. Note that I don't propose to abandon the dynamic access functionality, which is certainly useful and desirable in a number of specific situations. I simply point out that the performance penalty of dynamic access is unjustified for static use. -- Jean-Yves Lefort <jylefort brutele be>
Attachment:
pgpdBWxKNMO3H.pgp
Description: PGP signature