[Development] qt_add/removeObject hooks

[André Pönitz]

On Tue, Apr 08, 2014 at 11:00:18PM +0200, Olivier Goffart wrote:
> On Tuesday 08 April 2014 07:42:46 Thiago Macieira wrote:
> > Em ter 08 abr 2014, às 15:49:16, Volker Krause escreveu:
> > > API-wise we are quite flexible (can't get any more dirty than what we do
> > > now ;) ), I was mainly asking due to this being on a performance-relevant
> > > path. The QInternal callback system is obviously more flexible (and thus
> > > would be my preferred choice), but also slightly more expensive at
> > > runtime. The signal spy approach would be slightly more light-weight, at
> > > the cost of thread-safety. So, if from the performance point of view
> > > there are no objections to the QInternal callback approach, I'll make
> > > sure the Squish team is happy with that too, and propose a patch
> > > accordingly.
> > 
> > Performance-wise, I'd prefer empty functions that get overridden at runtime.
> > That's the smallest overhead for when they are not present.
> 
> According to a quick benchmark (attached), it is clearly more efficient to 
> have:
>   if (callback) callback();
> where callback is a function pointer than always calling callback even if it 
> is an empty function.
> 
> For this reason, I'd recommend an approach based on function pointer callbacks 
> such as QInternal::registerCallback
> (but that one is using a QGlobalStatic, so there is room for improvement)

I don't think there's a need to get overly fancy with a registration
interface for such things. This is not "common user API", but
special-purpose access for tools that are already heavily tied to Qt core
guts anyway, in an attempt to make their maintenance simpler while not
disturbing normal operation.

Function pointers are fine (after your measurement preferably set to 0 by
default and checked on call), but don't need to be accessible to any kind
of "public" beyond what the tools need for their operations.

Speaking for debugging here, I'd be happy enough to have a reliable method
to access some compile-time constants that are not easily accessible at
run time. In this context, finding a global symbol is easy, some arithmetic
is easy, but function calls are prohibitive. So putting all the needed
compile-time constants into one global array without further fuzz is pretty
much optimal.

Using an array of function pointers for QObject construction/destruction
hooks or similar would serve to my best understanding a similar purpose for
e.g. GammaRay (Volker, feel free to correct me), using quintptr and merging
both arrays just saves a symbol and keeps the naughty parts in a single
place. Arrays are also easily extensible without intoducing more symbols.

Andre'