Re: shortcuts for g_type_register_static_simple

[Stefan Kost <ensonic hora-obscura de>]

Sorry for the spam, but readelf thinks otherwise:
$ readelf -d ../lib/test-before.so | grep REL
 0x00000002 (PLTRELSZ)                   3520 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x6dd0
 0x00000011 (REL)                        0x6a30
 0x00000012 (RELSZ)                      928 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffa (RELCOUNT)                   95
$ readelf -d ../lib/test-after.so | grep REL
 0x00000002 (PLTRELSZ)                   3536 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x6e20
 0x00000011 (REL)                        0x6a90
 0x00000012 (RELSZ)                      912 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffa (RELCOUNT)                   93

so it seems that by using g_type_register_static_simple we can save 2  
relocs and there are 16bytes moved from (RELSZ) to (PLTRELSZ).

Stefan

Quoting Stefan Kost <ensonic hora-obscura de>:

> hi,
>
> I just converted one of my classes to use G_DEFINE_TYPE to benefit
> from less typing and from the less relocations. When trying it I was
> suprised to see that it actally adds two more relocations:
>
> $ LD_DEBUG=statistics ./test-before
>       30264:                      number of relocations: 2566
>       30264:           number of relocations from cache: 2403
>       30264:             number of relative relocations: 23747
>       30264:
>       30264:     runtime linker statistics:
>       30264:                final number of relocations: 7783
>       30264:     final number of relocations from cache: 2407
> $ LD_DEBUG=statistics ./test-after
>       31894:                      number of relocations: 2566
>       31894:           number of relocations from cache: 2403
>       31894:             number of relative relocations: 23745
>       31894:
>       31894:     runtime linker statistics:
>       31894:                final number of relocations: 7785
>       31894:     final number of relocations from cache: 2407
>
> Anyone an idea whats causing this?  Matthis do you remember how you
> verified that this helps?
>
> Stefan
>
> Quoting Tim Janik <timj gtk org>:
>
> > On Tue, 8 May 2007, Stefan Kost wrote:
> >
> > > 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
> >
> > yeah, known bottlenecks. the issue with those two functions is really
> > that they
> > are being called from an insane amount of places. we've tried to   
> > squeeze best
> > performance out of those already (normal type is_a checks are O(1),  
> >  interface
> > type is_a checks are O(ld(n_ifaces_per_type))). there don't seem to be
> > any easy
> > fruits left in here.
> > we've even implemented obvious call reductions here already, e.g. see the
> > __r = TRUE branch in the implementation of G_TYPE_CHECK_INSTANCE_TYPE():
> >
> > #  define _G_TYPE_CIT(ip, gt)             (G_GNUC_EXTENSION ({ \
> >   GTypeInstance *__inst = (GTypeInstance*) ip; GType __t = gt;
> > gboolean __r; \
> >   if (__inst && __inst->g_class && __inst->g_class->g_type == __t) \
> >     __r = TRUE; \
> >   else \
> >     __r = g_type_check_instance_is_a (__inst, __t); \
> >   __r; \
> > }))
> >
> > > Nothing big to gain here, so it seems.
> > >
> > > Stefan
> >
> > ---
> > ciaoTJ
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list