[Gammaray-interest] Thoughts about the problem scanner

[Volker Krause]

On Saturday, 23 March 2019 15:39:54 CET Christian Gagneraud wrote:
> On Wed, 20 Mar 2019 at 09:41, Volker Krause <volker.krause at kdab.com> wrote:
> > > IMHO, some models should contains these dynamic data in a more
> > > processed way, eg AbstractConnectionsModel contains static data, while
> > > SignalHistoryModel contains "raw" dynamic data, eg. start/end time (of
> > > the connect/disconnect?). no start/stop at the event level (?!?), no
> > > trigger counter, no accumulated process time, ...
> > > 
> > > So Am I right that to get that started, i would first need to enhance
> > > the SignalHistoryModel?
> > > I don't see the point to do all the tracking/calculation in the GUI
> > > part, or in another (new) class or I will end up duplicating code from
> > > the signal history view.
> > 
> > Yes, I don't think we have the data needed for this in the right form
> > already.
> > 
> > There's two sources of data available I think:
> > - connections: Unlike in Qt4 we don't have hooks to be notified about
> > connects/disconnects anymore, so we can only list connections on demand
> > for a given object. That's what the xConnectionModel classes do, as well
> > as the connection issue scanner. That's also the reason why we have no
> > model available anymore with all existing connections.
> > - signal emissions: For those we have very high level of detail hooks
> > (begin/ end signal emission, begin/end slot invocation), which is what
> > the signal history model collects.
> 
> Thanks for the info, that's a pity we don't have hooks for
> connect/disconnect :(

It's not unthinkable to add those though, but that would become available 
earliest in Qt 5.14 then.

> > The signal history model is already quite expensive, you certainly don't
> > want to transfer that entirely to the client just to sum up costs for
> > example, so doing aggregation in there makes a lot of sense. A useful
> > intermediate step to verify the data is all there might be to show
> > emission data in the connections tab of an object.
> 
> I guess, what's expensive is the list of event, that keep growing,
> right? And the fact that the object list never shrink as well?

Exactly, unbound memory consumption combined with the high frequency emission 
of some signals (eg. from render or event loops). We already try to exclude 
some of the worst built-in offenders, but that is of course skewing the 
results.

> As well, this history model only tracks signals, no slots, are you OK
> if I add slot tracking too?

To make this really useful we need to track that too, yes. We might get to the 
point where we need a way to limit the memory consumption though, by having a 
fixed limit and purging older records, or by making the full tracking opt-in, 
etc. Depends how expensive this really turns out to be I guess.

> > However, If you primarily care about the connection structure rather than
> > the emission data, producing a graphviz dot file with code similar to the
> > connection issue scanner should already be doable, maybe with some
> > filtering applied to hide non-connected objects to keep the result
> > readable.
> Yes, but this is server-side code. Ideally I would prefer to generate
> it in the client/gui side...

Right, that is conceptually the cleaner approach of course. We might need to 
look at more efficient ways to transfer the data than the commonly used remote 
model view approach though. That's optimized for interactivity rather than 
efficient transfers, and it's not offering a convenient way for you to know 
you downloaded everything you need. The Qt Quick remote view might offer some 
inspiration for alternatives.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4664 bytes
Desc: not available
URL: <http://mail.kdab.com/pipermail/gammaray-interest/attachments/20190325/10231fca/attachment.p7s>