504504 <p>
505505 The bottom up view did an excellent job of determining that the get_Now() method
506506 as well as the 'SpinForASecond' consume the largest amount of time and thus
507- are worth looking at closely. This corresponds beautify
507+ are worth looking at closely. This corresponds
508508 to our expectations given the source code in <a href="Tutorial.cs.txt">Tutorial.cs</a>.
509509 However it can also be useful to understand where CPU time was consumed from the
510510 top down. This is what the <a href="#CallTreeView">CallTree view</a> is for.
529529 stacks), which typically run in the 5-10% range. In this case it seems
530530 to be about 6%). The 'When' column also clearly shows how one
531531 instance of RecSpin runs SpinForASecond (for exactly a second) and then calls a
532- RecSpinHelper which does consumes close to 100% of the CPU for the rest of the time.
532+ RecSpinHelper which consumes close to 100% of the CPU for the rest of the time.
533533 . The call Tree is a wonderful top-down synopsis.
534534 </p>
535535 <h4>Getting a 'coarser' view</h4>
@@ -539,9 +539,9 @@ <h4>Getting a 'coarser' view</h4>
539539 use this fact and the 'Fold %' functionality to get an even coarser view
540540 of the 'top' of the call tree. With all nodes expanded, simply
541541 right click on the window and select 'Increase Fold %' (or easier hit the
542- F7 key). This increases the number it the Fold % textbox by 1.6X.
542+ F7 key). This increases the number in the Fold % textbox by 1.6X.
543543 By hitting the F7 key repeatedly you keep trimming down the 'bottoms' of
544- the stacks until you only see only the methods that use a large amount of CPU time.
544+ the stacks until you only see methods that use a large amount of CPU time.
545545 The following image shows the CallTreeView after hitting F7 seven times.
546546 </p>
547547 <center>
@@ -1804,7 +1804,7 @@ <h4>
18041804 <p>
18051805 A typical GC Memory investigation includes dump of the GC heap. While this gives
18061806 very detailed information about the heap at the time the snapshot was taken, it
1807- give no information about the GC behavior over time. This is what the GCStats report
1807+ gives no information about the GC behavior over time. This is what the GCStats report
18081808 does. To get a GCStats reports you must <a href="#CollectingData">Collect Event Data</a>
18091809 as you would for a CPU investigation (the GC events are on by default). When you
18101810 open the resulting ETL file one of the children will be a 'GCStats' view. Opening
0 commit comments