From 6dd86a3986c49e0f60d8af9ac87ee6ed36aa65d9 Mon Sep 17 00:00:00 2001 From: Christian Hergert Date: Fri, 7 Feb 2020 19:12:09 -0800 Subject: [PATCH] remove stale TODO --- TODO | 46 ---------------------------------------------- 1 file changed, 46 deletions(-) delete mode 100644 TODO diff --git a/TODO b/TODO deleted file mode 100644 index 7ffc43ab..00000000 --- a/TODO +++ /dev/null @@ -1,46 +0,0 @@ -# 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. -