Demo

[fhilgers]

No description provided.

[fhilgers]

@SergejIsbrecht I've tried to incorporate many of your suggestions:

• usecase one (fictive one) removed
• explicitly mention "always on"
• mention that one does live debugging, but rather that the collection happens all the time and the data can be analyzed later
• mention the aspect that this project is just a building block / part of a software that eSolutions might employ
• mention that it was designed this way from the start, e.g. visualization and event collection is completely decoupled -> makes it easier to use as building block a complete solution with for example vector or similar

To underline both aspects, the usecases are split into two parts: Visualization and Event Collection:

Visualization

• explicitly mention the use of fake data
• mention that in a final product, such a visualization would be used with already collected data, not a running system
• Otherwise this is the same as previous usecase 2

Event Collection

• Collects real data (data will be mostly random, but the fact that everything can be collected is the goal of this part)
• go into the low profile (e.g. top show that the thing has not much overhead -> can always run)

While the time was to little to write a vector integration, I've tried to build something similar, just a bit simpler: Dump everything into sqlite.

We can run this part while the first demo is taking place, and then do some sample queries to demonstrate what can be collected.

I've limited this to Garbage Collection and write events, because they make for the best showcase of data in my opinion.

• mention that while this tool (e.g. the sqlite storage) will not be used be eSolutions, it showcases that our project successfully works as a building block for other apps, because building such integration is quite simple (e.g. one evening)

I know it is too late to ask for feedback, but the team will be meeting at 9 o'clock so we can finalize things.

[SergejIsbrecht]

Ich schaue gleich rueber

[SergejIsbrecht]

mention that one does live debugging, but rather that the collection happens all the time and the data can be analyzed later

I would imply both are viable options. Mostly using offline data, but also used for live "debugging". For example: open an app and scroll through screens and look at the GC statistics while doing it. You could identify memory leaks or screens allocating a lot without the need to attach Android Studio | perfetto.

go into the low profile (e.g. top show that the thing has not much overhead -> can always run)

You should probably also show https://github.com/Netflix/bpftop and demonstrate the overhead of uprobes (µsec), but at this point top is good enough.

[SergejIsbrecht]

Ansonsten, looks good to me.

Viele Erfolg für die Presentation