![(please configure the [header_logo] section in trac.ini)](/ThreadScope/chrome/site/your_project_logo.png){kind=logo}
Changes between Version 10 and Version 11 of RTSsummaryEvents
- Timestamp:
- 12/21/11 08:01:26 (17 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
RTSsummaryEvents
v10 v11 21 21 Either a separate event for that, perhaps emitted only after major GC, when we know how much memory 22 22 is really used by the program (the docs explain the "n samples" saying "only checked during major garbage collections"). 23 Or try to calculate it from all events. in particular memory deallocation events or GC memory freeing events.23 Or try to calculate it (how often to sample?) from all events. in particular memory deallocation events or GC memory freeing events. 24 24 25 25 {{{ … … 58 58 (if RequestParGC is not enough to tell seq/par). Note that we don't want 59 59 to report the CPU time, only the elapsed time, and that's fine. 60 With the current GC events only summarized information is available.61 60 62 61 {{{ … … 79 78 80 79 Ask JaffaCake how the "tasks" relate to the "threads" for which we generate 81 events. Perhaps in the existing GC evensadd the info about which task80 events. Perhaps to the existing GC events we can add the info about which task 82 81 does the job. BTW, is the time between event GCIdle and GCWork counted 83 82 as GC time of the task? Generally, is GCIdle useful for us here in any way? … … 105 104 106 105 (Note that there may be more positions here, e.g., for profiling.) 107 We can sum up the times from GC events. For other stats, we'd needthe MUT108 figure, but it's not obvious if we manage to get it from all the thread (task)109 events that we have and will add above. It's also not clear if adding events110 needed to get the other times is worth it. After a ll the otherevents106 We can sum up the GC time from GC events. We'd also like to have the MUT 107 figure, but it's not obvious if we can manage to get it from all the thread (task) 108 events that we have (or add above). It's also not clear if adding events 109 needed to get the other times is worth it. After any extra events 111 110 are added, let's see if we can get any more of these summary times, 112 111 perhaps by adding a minor event emitted just once. Note that the INIT time is 113 necessary for the Productivity figure below ( itdoes not count as "productive112 necessary for the Productivity figure below (INIT does not count as "productive 114 113 time" in +RTS -s).. 115 114 … … 132 131 }}} 133 132 134 The events added above should be enough. Again. we only do the elapsed case. 133 The events added above should be enough. Again. we only do the elapsed case. 134 Ask JaffaCake if it's OK that the "% of total elapsed" in +RTS -s is actually the CPU time divided by elapsed time.
