Re: shortcuts for g_type_register_static_simple
- From: Stefan Kost <ensonic hora-obscura de>
- To: Tim Janik <timj gtk org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: shortcuts for g_type_register_static_simple
- Date: Tue, 08 May 2007 12:31:21 +0200
I was reffering to the idea Matthis Clasen mentioned in this thread:
I look at my own application. Refdbg tells me that I use 162 different
types. So the overhead seems to be acceptable. Running oprofile shows
these two top in the report for libgobject which itself has 7 % of the
168 11.2299 g_type_check_instance_is_a
118 7.8877 g_type_is_a
Nothing big to gain here, so it seems.
Quoting Tim Janik <timj gtk org>:
On Mon, 7 May 2007, Stefan Kost wrote:
wasn't the g_type_register_static_simple() meant to avoid the memcpy()
of filling the GTypeInfo only to pass it to type_data_make_W, which
then copies most filed from this elsewhere?
no, the code in question is not time critical in the sense that you'd
ever notice a structure memcpy or not. it's not like you could call it
in a loop for several million times to expose a timing difference.
Then shouldn't type_data_make_W() be reflowed. There is a big if()
elseif(), elseif() else in there. Implementations should know if what
the instance is instantiable, classed or an interface. They could
directly call instantiable_type_data_make_W(),
classed_type_data_make_W(), ... and these make some unconditional
calls at top/bottom to share common functionality.
huh? do you want to forbid conditionals in code from now on, or what
is this about? i don't see a reason to "reflow" type_data_make_W(),
whatever it is you mean by that ;) what you suggest sounds way more
complex than the current code.
there is simply no need to tear the code apart and you are not
providing a rationale for doing it.
Then its the
question wheter the specific variants could avoid the copy from
GTypeInfo to InstanceData, ClassData or IFaceData. Couldn't they also
receive the GtypeInfo fields as parameters?
what's this "avoid copy of a handful structure fields" about?
i highly doubt that you can provide any data that an int-copy or
a bunch of pointer-copies in run-once code have a severe performance
in any case, such data would have to be presented first, before we talk
about particular code changes. that's so we can avoid premature
optimizations and adress real problem areas:
] [Thread Prev