Previously Profiler (e.g. when started via the context menu in
SystemMonitor) would request logging _all_ event types. While this
might be useful at a later point in time the lack of event type
filtering in the profile viewer makes this less useful because
showing different event types in the same timeline shows an inaccurate
picture of what was really going on.
Some event types (like kmalloc) happen more frequently than others
(e.g. CPU samples) and while they don't carry the same weight they
would still dominate the samples graph.
This changes the Profiler app to just do CPU sampling for now.
Since the introduction of multi-select, we have had both `on_selection`
and `on_selection_change`, the latter of which was only invoked when a
change in selection came in through the model.
This removes `AbstractView::on_selection` and replaces it usage with
the more explicit `on_selection_change` everywhere.
We were not taking the width of the process headers into account when
computing the scrollable content size of the timeline.
Fix this by passing the header width to AbstractScrollableWidget's
set_size_occupied_by_fixed_elements().
I've had a couple of instances where a profile was missing process
creation events for a PID. I don't know how to reproduce it yet,
so this patch merely adds a helpful debug message so you know why
Profiler is failing to load the file.
This patch adds an additional level of hierarchy to the call tree:
Every process gets its own top-level node. :^)
Before this, selecting multiple processes would get quite confusing
as all the call stacks from different processes were combined together
into one big tree.
Problem:
- Default destructors (and constructors) are in `.cpp` files. This
prevents the compiler's optimizer from inlining them when it thinks
inlining is appropriate (unless LTO is used).
- Forward declarations can prevent some optimizations, such as
inlining of constructors and destructors.
Solution:
- Remove them or set them to `= default` and let the compiler handle
the generation of them.
- Remove unneeded forward declarations.
Hiding those frames doesn't really make sense. They're a major
contributor to a process' spent CPU time and show up in a lot of
profiles. That however is because those processes really do spend
quite a bit of time in the scheduler by doing lots of context
switches, like WindowServer when responding to IPC calls.
Instead of hiding these for aesthetic reasons we should instead
improve the scheduler.
We can lose profiling timer events for a few reasons, for example
disabled interrupts or system slowness. This accounts for lost
time between CPU samples by adding a field lost_samples to each
profiling event which tracks how many samples were lost immediately
preceding the event.
Now that the profiling timer is independent from the scheduler the
user will get quite a few CPU samples from "within" the scheduler.
These events are less useful when just profiling a user-mode process
rather than the whole system. This patch adds an option to Profiler to
hide these events.
Previously Profiler would use the stack depth to draw the timeline
graphs. This is not an accurate representation of whether a thread
is "busy" or not. Instead this updates the timelines to use the
sample count.
There is no need to iterate through all events in a profile when
loading the timeline view, as soon as we see one event we can
move on to the next process.
The architecture here is a little bit convoluted. I ended up making a
new container widget (TimelineContainer) that works similarly to
GUI::ScrollableContainerWidget but has two subwidgets (a fixed header
that only scrolls vertically, and the timeline view that scrolls on
both axes.)
It would be nice to generalize this mechanism eventually and move it
back into LibGUI, but for now let's go with a special widget for
Profiler so we can continue iterating on the GUI. :^)
Instead of smashing together all the samples into a single timeline,
make one per process and put them all in a ScrollableContainerWidget.
This makes it much easier to see which processes were active and when.
No timeline is displayed for processes with zero samples in the profile.
This turns the perfcore format into more a log than it was before,
which lets us properly log process, thread and region
creation/destruction. This also makes it unnecessary to dump the
process' regions every time it is scheduled like we did before.
Incidentally this also fixes 'profile -c' because we previously ended
up incorrectly dumping the parent's region map into the profile data.
Log-based mmap support enables profiling shared libraries which
are loaded at runtime, e.g. via dlopen().
This enables profiling both the parent and child process for
programs which use execve(). Previously we'd discard the profiling
data for the old process.
The Profiler tool has been updated to not treat thread IDs as
process IDs anymore. This enables support for processes with more
than one thread. Also, there's a new widget to filter which
process should be displayed.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
This warning informs of float-to-double conversions. The best solution
seems to be to do math *either* in 32-bit *or* in 64-bit, and only to
cross over when absolutely necessary.
I hereby declare these to be full nouns that we don't split,
neither by space, nor by underscore:
- Breadcrumbbar
- Coolbar
- Menubar
- Progressbar
- Scrollbar
- Statusbar
- Taskbar
- Toolbar
This patch makes everything consistent by replacing every other variant
of these with the proper one. :^)
The previous names (RGBA32 and RGB32) were misleading since that's not
the actual byte order in memory. The new names reflect exactly how the
color values get laid out in bitmap data.
