varun-r-mallya/sysprof
1
0
Fork 0
mirror of https://github.com/varun-r-mallya/sysprof.git synced 2025-12-31 20:36:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add "total" field.

Browse Source 
Mon Oct 31 23:41:33 2005  Soeren Sandmann  <sandmann@redhat.com>

        * stackstash.h (struct StackNode): Add "total" field.

        * stackstash.c (stack_stash_add_trace): Keep track of the
        aggregate size.

        * profile.c (profile_get_size): Sum the totals of the siblings
        instead of all the children.

        * profile.c (build_object_list): Correctly compute obj->self

        * profile.c (profile_load): Don't ignore the node->total field.

        * profile.c (serialize_call_tree): Save node->total instead of the
        computed total

        * profile.c (compute_total): Use n->total instead of computing it
        from scratch.

        * profile.c: Remove unused sum_children() function.

        * TODO: Updates

        * process.c (process_get_from_pid): Plug leak.
This commit is contained in:
Soeren Sandmann
2005-11-01 04:37:16 +00:00
committed by Søren Sandmann Pedersen
parent 81ad181667
commit c778a1b1ec
7 changed files with 62 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
TODO
View File

@ -15,6 +15,8 @@ Before 1.0.1:
Before 1.2:
* Don't build the GUI if gtk+ is not installed
* Handle time being set back in the RESET_DEAD_PERIOD code.
* Find out if the first sort order of a GtkTreeView column can be changed
@ -31,8 +33,6 @@ Before 1.2:
(Reported by Kjartan Maraas).
- Fix bugs/performance issues:
- total should probably be cached so that compute_total() doesn't
take 80% of the time to generate a profile.
- decorate_node should be done lazily
- Find out why we sometimes get completely ridicoulous stacktraces,
where main seems to be called from within Xlib etc. This happens
@ -47,6 +47,9 @@ Before 1.2:
process b spends 1% in foo() called from baz()
we get reports of baz() using > 80% of the time.
Or something.
- add_trace_to_tree() might be a little slow when dealing with deeply
recursive profiles. Hypothesis: seen_nodes can grow large, and the
algorithm is O(n^2) in the length of the trace.
- make the things we put in a stackstash real
objects so that
@ -422,6 +425,9 @@ Later:
DONE:
- total should probably be cached so that compute_total() doesn't
take 80% of the time to generate a profile.
- Fixing the oops in kernels < 2.6.11
- Probably just require 2.6.11 (necessary for timer interrupt