[Gammaray-interest] Object connectivity inspector/viewer

[Volker Krause]

On Friday, 10 May 2019 13:55:45 CEST Christian Gagneraud wrote:
> [another old draft email, sending it in the hope to bring the discussion
> back]
> 
> Hi,
> 
> Starting a new thread.
> 
> As i started coding, i'm slowly realising that the signal history
> model might not be the right tool to work on/with.
> First, from personal experience, i do not find it that useful, and as
> i usually use Gammaray on a big App, it tends to be too slow and
> sometimes causes instability.
> IMHO, I think having something like the meta-object model would be more
> useful. A simple tree, with objects as root nodes (parenting ignored), and
> signal/slots as leaf nodes. then columns would be: object/method name,
> endpoint object, enpoint method name, invocation count, and
> accumulated duration, no need for fancy "scope-like" drawing. The type
> of connection can be shown with the decoration role.
> Or maybe even more simple, just a table model.

That indeed would be more useful to identify hotspots, especially in large 
applications. It's also in line with what we are trying with the event monitor 
at the moment. The timeline plots can be useful too, but probably not for all 
objects at once.

> The tree view would be on the left, and on the right side, would be
> the graph(s) and the mechanism to filter/select object of interest
> (TBD).
> 
> Connectivity map
> I have a stupid/simple PoC for the connectivity map, it doesn't yet
> contain meta-data, but the result is IMHO interesting. The only
> problem is that it is generated as a dot file on the target (inside
> the ObjectInspector). If i want to implement this on the GUI side,
> that would be better to have a more suited model - my understanding is
> that the GUI has only access to remote models, so i'll have to rely on
> models, is it correct?

Models and objects registered with ObjectBroker, yes. Objects most of the time 
are not providing data though but ways to interact with the target, so 
practically it's going to be models.

One option is to implement a better suited model and export that to the 
client. Or you implement the entire generation server-side and just send the 
result to the client, less elegant but might be simpler as it avoids dealing 
with the asynchronous model loading.

> As well, i would like to render the graph in the UI, for a start i'm
> thinking about generating an SVG and simply display it.
> I think that a weighted graph would be perfect for that job, no
> details about signal/slots, just weight b/w objects.
> See attached dot files, generate png with "dot -O -Tpng graph1.dot"

Very nice! The second one nicely shows the potential of this by highlighting 
the cross-thread communication.

Regarding rendering dot graphs, SVG is probably a good way to get started. One 
usual problem with dot graphs however is how they grow for larger data. To 
manage that you might end up wanting an interactive display with tooltips or 
the ability to select nodes/edges to highlight or filter them. Not something 
one wants to write from scratch, but I remember KCachegrind and Massif 
Visualizer having such views, maybe there's reusable components for this 
already.

> Connection cascading
> Haven't try that one yet, but it is definitely an interesting one,
> that one would require details about signal/slot, threading,
> connection type, ...
> 
> Scope
> Maybe the current scope could be integrated somehow.
> 
> Object vs class.
> As well IMHO, it would be nice to have an "object" view and a "class"
> view. As you might be interested to look at your metrics on a class
> basis, eg. Which class(es) it generating the most "traffic". Which
> classes are strongly coupled, ... Maybe something for a distant
> future.

Good point! Shouldn't be too hard even, as this is "just" mapping to 
QObject::metaObject(). The per class metrics in the meta object view already 
turned out much more useful than initially expected.

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/20190514/652983ec/attachment.p7s>