Amended docs.

Author: simphotonics

README.md

@@ -217,7 +217,7 @@ the enclosing group.
 ## Score Sampling
 
 For more information about benchmark score sampling see the dedicated [section](
-  https://github.com/simphotonics/benchmark_runner/gnuplot
+   https://github.com/simphotonics/benchmark_runner/tree/main/gnuplot
 ).
 
 

example/README.md

@@ -22,8 +22,6 @@ Write inline benchmarks using the functions:
  asynchronous benchmarks.
 
   ```Dart
-  // ignore_for_file: unused_local_variable
-
   import 'package:benchmark_runner/benchmark_runner.dart';
 
   /// Returns the value [t] after waiting for [duration].
@@ -32,14 +30,15 @@ Write inline benchmarks using the functions:
   }
 
   void main(List<String> args) async {
-    await group('Wait for duration', () async {
+
+   await group('Wait for duration', () async {
       await asyncBenchmark('10ms', () async {
         await later<int>(39, Duration(milliseconds: 10));
       });
 
       await asyncBenchmark('5ms', () async {
         await later<int>(27, Duration(milliseconds: 5));
-      }, emitStats: false);
+      }, scoreEmitter: MeanEmitter());
     });
 
     group('Set', () async {
@@ -50,11 +49,8 @@ Write inline benchmarks using the functions:
       benchmark('construct', () {
         final set = {for (var i = 0; i < 1000; ++i) i};
       });
-
-      throw 'Error in group';
     });
   }
-
   ```
 Run a *single* benchmark file as an executable:
 ```Console
@@ -66,7 +62,7 @@ by calling the benchmark_runner and specifying a directory.
 If no directory or file name is specified, then it defaults to `benchmark`:
 
 ```Console
-$ dart run benchmark_runner
+$ dart run benchmark_runner report
 ```
 
 ## Features and bugs

gnuplot/README.md

@@ -5,7 +5,7 @@
 ## Introduction
 
 When benchmarking a function, one has to take into consideration that
-the test is not performed on an isolated system that is only handling the
+the benchmark is not performed on an isolated system that is only handling the
 instructions provided by our piece of code. Instead, the CPUs is very likely
 busy performing other tasks before eventually executing the benchmarked code.
 This introduces latency that is typically larger for the first few runs
@@ -15,9 +15,8 @@ where the first few runs are discarded.
 
 A second factor to consider are systematic measuring errors due to the fact
 that it takes (a small amount of) time to increment loop counters, perform
-loop checks, or access the elapsed time.
-
-The overhead introduced by repeatedly accessing the
+loop checks, or access the elapsed time. The overhead introduced by
+repeatedly accessing the
 elapsed time can be reduced by averaging the
 benchmark score over many runs.
 
@@ -47,7 +46,7 @@ in microseconds.
 For short run times below 1 microsecond each score sample is generated
 using the functions [`measure`][measure] or the equivalent
 asynchronous method [`measureAsync`][measureAsync]. The cyan curve shows
-approx. over how many runs a score entry is averaged.
+over how many runs each score entry is averaged.
 
 ### Custom Sampling Method