Re: shortcuts for g_type_register_static_simple


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 total time.
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:



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