mirror of
https://github.com/varun-r-mallya/sysprof.git
synced 2025-12-31 20:36:25 +00:00
47 lines
1.6 KiB
Plaintext
47 lines
1.6 KiB
Plaintext
# TODO
|
|
|
|
- Follow fork/threads
|
|
|
|
Currently, when watching a pid, we do not have a way to follow forks.
|
|
We need to watch FORK/EXIT events and create/dispose additional perf
|
|
streams from the kernel.
|
|
|
|
- Add cpu/mem/net data source
|
|
|
|
- Add frame types for generic counters
|
|
|
|
- Add support for visualizations other than the callgraph.
|
|
|
|
1) I'd like to see a graph of call depth over time.
|
|
2) line graphs for cpu/mem/net.
|
|
3) disk I/O
|
|
|
|
etc.
|
|
|
|
One quick way to put together the UI is to just use ListBox for the
|
|
rows. Then we need a "graph" child that allows drawing. The nice thing
|
|
here is that we get pixel caching for free. Resizing the row height
|
|
gets a little annoying though.
|
|
|
|
- Remote Profiler Support
|
|
|
|
SpProfiler is an interface, for which we only currently have an
|
|
SpLocalProfiler implementation. It would be nice to gain a
|
|
SpRemoteProfiler that can use SSH to connect to another machine
|
|
and run the sysprof-cli client. The couple of tricky parts are
|
|
going to revolve around setting up sources.
|
|
|
|
- Specify Debug Directory (or alternative)
|
|
|
|
When analyizing profiling information from another machine, we need access
|
|
to the symbols. Currently, we have no way to do this, but it would be nice
|
|
if we could have one of two ways to resolve this issue:
|
|
|
|
1) When finishing up the profiling session, we could do a pass through all
|
|
the symbols and extract them on the target machine. We could then append
|
|
this information with a new CaptureFrame type to the capture.
|
|
2) Specify a directory to load debug symbols from.
|
|
|
|
I think my preference is #1.
|
|
|