Files
sysprof/TODO
Søren Sandmann e9bd305866 Return NULL if nothing is selected.
Fri Mar 25 21:25:31 2005  Søren Sandmann  <sandmann@redhat.com>

	* sysprof.c (get_current_object): Return NULL if nothing is
	selected.
2005-03-26 02:28:32 +00:00

153 lines
4.6 KiB
Plaintext

- Get this TODO file more organized
- Figure out what's needed before 1.0
- Consider what it would take to take stacktraces of other languages
- perl,
- python
- java
- bash
- Add support for line numbers within functions
- Consider adding KDE-style nested callgraph view
- Find out what distributions it actually works on
- Find out how to hack around gtk+ bug causing multiple double clicks
to get eaten.
- hook up about box
- Need an icon
- Add busy cursors,
- when you hit "Profile"
- when you click something in the main list and we don't respond within 50ms
(or perhaps when we expect to not be able to do so (can we know the size in
advance?))
- Need to make "make install" work (how do you know where to install kernel modules?)
- Sould just install the kernel module if it running as root, pop up a dialog if not.
- hook up menu items view/start etc (or possibly get rid of them or move them)
- Move "samples" label to the toolbar, then get rid of statusbar.
- consider caching [filename => bin_file]
- Have kernel module report the file the address was found in
Should avoid a lot of potential broken/raciness with dlopen etc.
- grep FIXME
- hide internal stuff in ProfileDescendant
- add an 'everything' object. It is really needed for a lot of things
- kernel module should put process to sleep before sampling. Should get us
more accurate data
- make profile.c more agnostic to processes and functions etc. Ideally
it should just take a set of stack traces containing "presentation
objects" and do something sensible with it.
- Non-GUI version that can save in a format the GUI can understand.
Could be used for profiling startup etc. Would preferably be able to
dump the data to a network socket. Should be able to react to eg.
SIGUSR1 by dumping the data.
- Port to GtkAction
- Charge 'self' properly to processes that don't get any stack trace at all
- figure out a way to deal with both disk and CPU. Need to make sure that
things that are UNINTERRUPTIBLE while there are RUNNING tasks is not
consider bad.
DONE:
- crashes when you ctrl-click the selected item in the top left pane
<ian__> ssp: looks like it doesn't handle the none-selected case
- loading and saving
- consider making ProfileObject more of an object.
- make an "everything" object
maybe not necessary -- there is a libc_ctors_something()
- make presentation strings nicer
four different kinds of symbols:
a) I know exactly what this is
b) I know in what library this is
c) I know only the process that did this
d) I know the name, but there is another similarly named one
(a) is easy, (b) should be <in ...> (c) should just become "???"
(d) not sure
- processes with a cmdline of "" should get a [pid = %d] instead.
- make an "n samples" label
Process stuff:
- make threads be reported together
(simply report pids with similar command lines together)
(note: it seems separating by pid is way too slow (uses too much memory),
so it has to be like this)
- stack stash should allow different pids to refer to the same root
(ie. there is no need to create a new tree for each pid)
The *leaves* should contain the pid, not the root. You could even imagine
a set of processes, each referring to a set of leaves.
- when we see a new pid, immediately capture its mappings
Road map:
- new object Process
- hashable by pointer
- contains list of maps
- process_from_pid (pid_t pid, gboolean join_threads)
- new processes are gets their maps immediately
- resulting pointer must be unref()ed, but it is possible it
just points to an existing process
- processes with identical cmdlines are taken together
- method lookup_symbol()
- method get_name()
- ref/unref
- StackStash stores map from process to leaves
- Profile is called with processes
It is possible that we simply need a better concept of Process:
If two pids have the same command line, consider them the same, period.
This should save considerable amounts of memory.
The assumptions:
"No pids are reused during a profiling run"
"Two processes with the same command line have the same mappings"
are somewhat dubious, but probably necessary.
(More complex kernel:
have the module report
- new pid arrived (along with mappings)
- mapping changed for pid
- stacktrace)
- make symbols in executable work
- the hashtables used in profile.c should not accept NULL as the key
- make callers work
- autoexpand descendant tree
- make double clicks work
- fix leaks