nits

Author: anupras-mohapatra-arm

content/learning-paths/servers-and-cloud-computing/go-gc-default-settings/create_gc_benchmark.md

@@ -64,7 +64,7 @@ func BenchmarkParseAndAllocate(b *testing.B) {
 	b.ReportAllocs()
 	
 	/*
-	Captures runtime memory statistics before the benchmark starts.  You'll later compare these values to see:
+	Captures runtime memory statistics before the benchmark starts. You'll later compare these values to see:
 	- how many GCs occurred
 	- how much pause time was spent in GC
 	*/
@@ -77,8 +77,8 @@ func BenchmarkParseAndAllocate(b *testing.B) {
 	b.ResetTimer()
 	
 	/*
-	Benchmark loop where the actual work is done.  The number of times this loop is
-	executed is controlled by the b.N variable.  The value of b.N is automatically chosen by the Go benchmark framework to obtain stable and statistically useful measurements.
+	Benchmark loop where the actual work is done. The number of times this loop is
+	executed is controlled by the b.N variable. The value of b.N is automatically chosen by the Go benchmark framework to obtain stable and statistically useful measurements.
 
 	The reason for this design is that timing a single operation is often unreliable. Running it many times reduces noise from:
 	- OS scheduling
@@ -90,7 +90,7 @@ func BenchmarkParseAndAllocate(b *testing.B) {
 		// splits the large payload into individual records.
 		// Example: "a=1;b=2;c=3;" becomes: ["a=1", "b=2", "c=3", ""]
 		parts := strings.Split(payload, ";")
-		// Creates a new slice to store parsed output.  This allocation is intentional for the benchmark to generate memory pressure and trigger GC activity.
+		// Creates a new slice to store parsed output. This allocation is intentional for the benchmark to generate memory pressure and trigger GC activity.
 		
 		out := make([]string, 0, len(parts))
 		

content/learning-paths/servers-and-cloud-computing/go-gc-default-settings/interpret_gc_results.md

@@ -40,7 +40,7 @@ Look for functions that dominate CPU time. In an allocation-heavy benchmark, you
 
 The `flat` column shows CPU time spent directly in that function. The `cum` (cumulative) column includes time spent in the function and all functions it called. A function with low `flat` but high `cum` is spending most of its time in callees, which can point to allocation chains or deep call stacks.
 
-On the validated `m8g.xlarge` instance, the top CPU profile entries included string scanning, string concatenation, split handling, and allocation paths:
+On the validated `m8g.xlarge` instance, the top CPU profile entries include string scanning, string concatenation, split handling, and allocation paths:
 
 ```text
       flat  flat%   sum%        cum   cum%
@@ -61,7 +61,7 @@ cat mem_default_alloc_top.txt
 
 Reducing allocation volume in those functions usually gives the Go garbage collector less work to do.
 
-On the validated `m8g.xlarge` instance, the allocation profile showed that `strings.genSplit` and the benchmark function accounted for nearly all allocated bytes:
+On the validated `m8g.xlarge` instance, the allocation profile shows that `strings.genSplit` and the benchmark function account for nearly all allocated bytes:
 
 ```text
       flat  flat%   sum%        cum   cum%

content/learning-paths/servers-and-cloud-computing/go-gc-default-settings/run_default_gc_benchmark.md

@@ -153,7 +153,7 @@ BenchmarkParseAndAllocate-4        66757            179173 ns/op
 PASS
 ```
 
-Inspect the CPU profile to display the functions that consumed the most CPU time during benchmark execution, ranked from highest to lowest:
+Inspect the CPU profile to list the functions that consumed the most CPU time during benchmark execution, ranked from highest to lowest:
 
 ```bash
 go tool pprof -top ./parsebench.test cpu_default.out | tee cpu_default_top.txt
@@ -177,7 +177,7 @@ Dropped 162 nodes (cum <= 0.08s)
      0.80s  5.08% 47.84%      2.71s 17.22%  runtime.mallocgcSmallScanNoHeader
 ```
 
-Inspect the heap allocation profile to display the functions responsible for allocating the most total memory over the lifetime of the benchmark, ranked from highest to lowest:
+Inspect the heap allocation profile to list the functions responsible for allocating the most total memory over the lifetime of the benchmark, ranked from highest to lowest:
 
 ```bash
 go tool pprof -top -alloc_space ./parsebench.test mem_default.out | tee mem_default_alloc_top.txt
@@ -205,7 +205,7 @@ Dropped 37 nodes (cum <= 0.06GB)
 
 You've now captured a default-GC benchmark result, a Benchstat summary, and CPU and heap profiles from the same workload. 
 
-Next, you'll analyze all of these results.
+Next, you'll analyze the benchmark results.
 
 
 

content/learning-paths/servers-and-cloud-computing/go-gc-default-settings/try_on_your_own.md

@@ -40,7 +40,7 @@ ParseAndAllocate-4               160.0Ki ± 0%   80.0Ki ± 0%  -50.00% (p=0.000)
 
 Assume that the payload size this benchmark is intended to represent is only 512 records instead of 2048. 
 
-To test whether a smaller workload affects GC frequency, pause times, and overall application performance, you can reduce the payload size from the following:
+To test whether a smaller workload affects GC frequency, pause times, and overall application performance, reduce the payload size from the following:
 
 ```go
 payload := strings.Repeat(
@@ -64,7 +64,7 @@ Reducing the payload size creates fewer temporary objects and less garbage each
 
 Assume that after profiling the application, you discover that the input payload rarely changes between requests. 
 
-To reuse preprocessing work and determine whether reducing repeated allocations improves GC behavior and throughput, you can update split logic from the following:
+To reuse preprocessing work, update split logic from the following:
 
 ```go
 for i := 0; i < b.N; i++ {
@@ -88,7 +88,7 @@ for i := 0; i < b.N; i++ {
 }
 ```
 
-By making this change, you can avoid repeatedly allocating the same slice of records on every iteration. Reducing repeated allocations improves GC behavior and throughput.
+By making this change, you can avoid repeatedly allocating the same slice of records on every iteration. Reducing repeated allocations improves GC behavior and throughput. 
 
 ### Reuse the output slice
 
@@ -118,7 +118,6 @@ for i := 0; i < b.N; i++ {
 
 By modifying the benchmark to reuse the backing array, you can reduce allocations and GC pressure.
 
-
 ### Replace SplitN() with IndexByte()
 
 Assume a CPU profile shows that string parsing is one of the hottest code paths in the application.