Luciana Lima Brito writes: > On Sat, 01 May 2021 09:16:08 +0100 > Christopher Baines wrote: > >> Currently the timing of various sections of the process includes >> timing smaller sections, and that may complicate reading the chart, >> since it won't convey which timed sections include other timed >> sections. Does that make sense? > > Yes, I understand. But just to make sure, you say that the actions we > see in the logs are actually subsections of a bigger process? The > problem here would be to clearly mark in the code actions of a same > process. I'll take this into account on my planning. Take the lint warnings for example, currently the time to fetch all lint warnings is timed, but the usage of each individual linter is timed. Both bits of information are helpful. > For that I propose to build 2 charts, one of the > macro view, what we call "overview first", showing the > sections(processes) and their whole time taken. This way we could just > see what we were aiming for, which is to identify slowness. > The second chart would be what we call "details on demand", in which we > could have the subsections(actions) being shown. To differ to which > section(process) they are bound, we could use two meaningless > alternating colours (just to group the subsections of a section), and > they would follow the same order as the first chart. > > The use of alternating colours could be applied to both charts in order > to make clear the equivalence. Both charts should appear at the same > time, one above the other, to ease comparison. That sounds better, although I think a timeline, similar to what the systemd-analyze example uses [1] might be a more natural representation of the data, colour could then be used to represent relatively how long each part takes. 1: https://lizards.opensuse.org/wp-content/uploads/2012/07/plot001.gif >> Great, this is a good amount of detail. > > I'll add this to the plan and to the final application, ok? Yep.