Re: shortcuts for g_type_register_static_simple

[Tim Janik <timj gtk org>]

On Mon, 7 May 2007, Stefan Kost wrote:

> hi,
>
> 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
impact.
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:
  http://en.wikipedia.org/wiki/Premature_optimization#When_to_optimize

> Stefan

---
ciaoTJ