Re: shortcuts for g_type_register_static_simple

[Stefan Kost <ensonic hora-obscura de>]

Hi,

I was reffering to the idea Matthis Clasen mentioned in this thread:
http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00169.html

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.

Stefan

Quoting 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