Re: GObject extension propose (GContainer)
On Sat, 17 Jun 2006, Tristan Van Berkom wrote:
Alan M. Evans wrote:
[...]
the lookup penalties are negligible.
type node/class lookups and is_a checks are O(1);
interface class lookups and conforms_to checks are O(ld(N)), where
N is the number of interfaces a type node conforms to.
Your assertion that the penalties are negligable is not really supported
by your response, unless the constant is also known for both orders.
From my swift glance at gtype.c, it seems that in the case of
an interface, the implementing interface is searched on that class's
list of implementing interfaces... so when classes implement
hundreds of interfaces it might be a performance hit.
no there won't be a performance hit.
that's because gtype.c uses a binary search for the
lookups (as indicated in my last email by the O(ld(N)) complexity).
the function used for frequent interface lookups is:
gpointer g_type_interface_peek (gpointer instance_class,
GTypeiface_type);
and in a nutshell, it does:
{
TypeNode *node = lookup_type_node_I (class-g_type);// O(1)
TypeNode *iface = lookup_type_node_I (iface_type); // O(1)
IFaceEntry *entry = type_lookup_iface_entry_L (node, iface); // O(ld(N))
return entry-vtable;
}
take a look at gtype.c and type_lookup_iface_entry_L() to confirm.
using a binary lookup in type_lookup_iface_entry_L() means, lookups in terms
of number of interfaces and node visits during the search relate like this:
interfaces-per-node | visits-per-lookup
1|1.0
2|2.0
3|2.6
4|3.0
5|3.3
6|3.6
8|4.0
16|5.0
32|6.0
64|7.0
128|8.0
256|9.0
512| 10.0
1024| 11.0
65536| 17.0
262144| 19.0
1048576| 21.0
67108864| 27.0
268435456| 29.0
2147483648| 32.0
that is, for all practical purposes, interface lookups are negligible even
for many thausands of interfaces implemented per node.
and now, please show me the OO system that gets into the hundreds at least...
Cheers,
-Tristan
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject extension propose (GContainer)
Alan M. Evans wrote: [...] the lookup penalties are negligible. type node/class lookups and is_a checks are O(1); interface class lookups and conforms_to checks are O(ld(N)), where N is the number of interfaces a type node conforms to. Your assertion that the penalties are negligable is not really supported by your response, unless the constant is also known for both orders. From my swift glance at gtype.c, it seems that in the case of an interface, the implementing interface is searched on that class's list of implementing interfaces... so when classes implement hundreds of interfaces it might be a performance hit. I dont think we've yet reached the day that we have to ditch good design and avoid using interfaces because of performance woes, that would be sorry day indeed... (I also dont think GTK+ code will be the only OO code needing major refactoring in those areas too... if these interface lookups weren't negligable) Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject extension propose (GContainer)
On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: Qui, 2006-06-15 às 13:00 -0400, Tristan Van Berkom escreveu: All of that just to say... I cannot count the times I've thought to myself that GtkContainer should really just be GContainerIface, and implemented by whatever interested objects that want to parent other objects... That's interesting, but I wonder what is the runtime penalty of interface lookup compared to normal class structure lookup? Is it really OK to use an interface for this, or is it better just to add a new virtual methods to the GObject class? the lookup penalties are negligible. type node/class lookups and is_a checks are O(1); interface class lookups and conforms_to checks are O(ld(N)), where N is the number of interfaces a type node conforms to. Gustavo J. A. M. Carneiro --- ciaoTJ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GObject extension propose (GContainer)
Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... Nicola ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject extension propose (GContainer)
On Thu, 15 Jun 2006, Fontana Nicola wrote: Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... hi. your gcontainer-1.0.0 looks like an interesting approach to me, but i'm not sure it's generally good to put that into stock libgobject. the main reason is that container needs are probably pretty variable out there (i've come across at least 4 different gobject container implementations in free software projects i'm woorking on) and that both, making too little assumptions in the child/container interface isn't going to be very helpful, albeit making too many has the same problem. i guess we could add a link to your project from the libgobject docs (it should probably have a Contrib section), for people possibly looking for a GObject container implementation. that way, gcontainer-1.0.0 gets a chance of being reused and maybe extended to something generally usefull for GObject applications out there. Nicola --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject extension propose (GContainer)
Tim Janik wrote: On Thu, 15 Jun 2006, Fontana Nicola wrote: Hi all, I'm a GObject based libraries (for UI purpose and not) user and I often need a generic container to derive my own types. In my opinion, I think this generic container must be included inside the GObject library ... it could be used by a lot of derived libraries providing a common approach. I published my solution - that is, what I am currently using - on sourceforge. http://sourceforge.net/projects/gcontainer/ Is it a good idea? Is something planned in this direction? Am I totally wrong? I need feedbacks ... As a side note... I've been working on container -- child relationships and honing them down inside the glade builder... objects may for example have object delagates that are owned and in turn may own other delagates... this is all functional with libglade facilities and the future gtk builder also (from the design as of yet...)... this concept of types of container relationships is also usefull for GtkMenuShell -- GtkMenu for example (not just any GtkWidget can be added to a menushell). All of that just to say... I cannot count the times I've thought to myself that GtkContainer should really just be GContainerIface, and implemented by whatever interested objects that want to parent other objects... I think that what we need is not really yet another container api, but a container api that is a unified front for generic handling of the GTK object hierarchy at runtime. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
