Update benchmarking.md

Author: pareenaverma

content/learning-paths/servers-and-cloud-computing/typescript-on-gcp/benchmarking.md

@@ -9,10 +9,11 @@ layout: learningpathall
 
 ## JMH-style Custom Benchmarking
 
-This section demonstrates how to **benchmark TypeScript functions** using a JMH-style approach with Node.js `perf_hooks`. Unlike simple `console.time` timing, this method performs **repeated iterations**, calculates the **average execution time**, and provides more **reliable and stable performance measurements** on your Arm64 SUSE VM.
+This section demonstrates how to benchmark TypeScript functions using a JMH-style (Java Microbenchmark Harness) methodology implemented with Node.js’s built-in `perf_hooks` module.
+Unlike basic `console.time()` measurements, this approach executes multiple iterations, computes the average runtime, and produces stable and repeatable performance data, useful for evaluating workloads on your Google Cloud C4A (Axion Arm64) VM running SUSE Linux.
 
 ### Create the Benchmark Script
-Create a file named `benchmark_jmh.ts` in your project folder:
+Create a file named `benchmark_jmh.ts` inside your project directory with the content below:
 
 ```typescript
 import { performance } from 'perf_hooks';
@@ -43,30 +44,34 @@ for (let i = 0; i < iterations; i++) {
 const averageTime = totalTime / iterations;
 console.log(`\nAverage execution time over ${iterations} iterations: ${averageTime.toFixed(3)} ms`);
 ```
+Code explanation:
 
-- **`performance.now()`** → Provides a high-resolution timestamp in milliseconds for precise timing measurements.  
-- **`sumArray`** → A sample CPU-bound function that sums numbers from 0 to `n`.  
-- **`iterations`** → Defines how many times the benchmark should run to stabilize results and minimize random variations.  
-- **`for` loop** → Executes the target function multiple times and records the duration of each run.  
-- **`totalTime / iterations`** → Calculates the **average execution time** across all runs, similar to how **JMH (Java Microbenchmark Harness)** operates in Java.  
+| Component               | Description                                                                                                                                                |
+| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **`performance.now()`** | Provides high-resolution timestamps (sub-millisecond precision) for accurate timing.                                                                       |
+| **`sumArray(n)`**       | A simple CPU-bound function that sums integers from 0 to `n`. This simulates a computational workload suitable for benchmarking raw arithmetic throughput. |
+| **`iterations`**        | Defines how many times the test runs. Multiple repetitions reduce noise and help average out one-off delays or GC pauses.                                  |
+| **Loop and averaging**  | Each run’s duration is recorded; the mean execution time is then reported, mirroring how JMH computes stable results in Java microbenchmarks.          |
 
-This JMH-style benchmarking approach provides **more accurate and repeatable performance metrics** than a single execution, making it ideal for performance testing on Arm-based systems.
+
+This JMH-style benchmarking approach provides more accurate and repeatable performance metrics than a single execution, making it ideal for performance testing on Arm-based systems.
 
 ### Compile the TypeScript Benchmark
-Compile the TypeScript benchmark file into JavaScript:
+First, compile the benchmark file from TypeScript to JavaScript using the TypeScript compiler (tsc):
 
 ```console
 tsc benchmark_jmh.ts
 ```
-This generates a `benchmark_jmh.js` file that can be executed by Node.js.
+This command transpiles your TypeScript code into standard JavaScript, generating a file named `benchmark_jmh.js` in the same directory.
+The resulting JavaScript can be executed by Node.js, allowing you to measure performance on your Google Cloud C4A (Arm64) virtual machine.
 
 ### Run the Benchmark
-Execute the compiled JavaScript file:
+Now, execute the compiled JavaScript file with Node.js:
 
 ```console
 node benchmark_jmh.js
 ```
-You should see an output similar to:
+You should see output similar to:
 
 ```output
 Iteration 1: 2.286 ms
@@ -85,21 +90,16 @@ Average execution time over 10 iterations: 0.888 ms
 
 ### Benchmark Metrics Explained
 
-- **Iteration times** → Each iteration shows the **time taken for a single execution** of the function being benchmarked.  
-- **Average execution time** → Calculated as the sum of all iteration times divided by the number of iterations. This provides a **stable measure of typical performance**.  
-- **Why multiple iterations?**  
-  - Single-run timing can be inconsistent due to factors such as CPU scheduling, memory allocation, or caching.  
-  - Repeating the benchmark multiple times and averaging reduces variability and gives **more reliable performance results**, similar to Java’s JMH benchmarking approach.  
-**Interpretation:**  
-- The average execution time reflects how efficient the function is under normal conditions.  
-- Initial iterations may take longer due to **initialization overhead**, which is common in Node.js performance tests.  
+  * Iteration times → Each iteration represents the time taken for one complete execution of the benchmarked function.
+  * Average execution time → Calculated as the total of all iteration times divided by the number of iterations. This gives a stable measure of real-world performance.
+  * Why multiple iterations?
+    A single run can be affected by transient factors such as CPU scheduling, garbage collection, or memory caching.
+    Running multiple iterations and averaging the results smooths out variability, producing more repeatable and statistically meaningful data, similar to Java’s JMH benchmarking methodology.
+    
+### Interpretation
 
-### Benchmark summary on x86_64
-To compare the benchmark results, the following results were collected by running the same benchmark on a `x86 - c4-standard-4` (4 vCPUs, 15 GB Memory) x86_64 VM in GCP, running SUSE:
-
-| Iteration | 1     | 2     | 3     | 4     | 5     | 6     | 7     | 8     | 9     | 10    | Average |
-|-----------|-------|-------|-------|-------|-------|-------|-------|-------|-------|-------|---------|
-| Time (ms) | 3.217 | 0.631 | 0.632 | 0.611 | 0.612 | 0.614 | 0.614 | 0.611 | 0.606 | 0.532 | 0.868   |
+The average execution time reflects how efficiently the function executes under steady-state conditions.
+The first iteration often shows higher latency because Node.js performing initial JIT (Just-In-Time) compilation and optimization, a common warm-up behavior in JavaScript/TypeScript benchmarks.
 
 ### Benchmark summary on Arm64
 Results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SUSE):
@@ -110,9 +110,10 @@ Results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm6
 
 ### TypeScript performance benchmarking comparison on Arm64 and x86_64
 
-When you compare the benchmarking results, you will notice that on the Google Axion C4A Arm-based instances:
+When you look at the benchmarking results, you will notice that on the Google Axion C4A Arm-based instances:
 
 - The average execution time on Arm64 (~0.888 ms) shows that CPU-bound TypeScript operations run efficiently on Arm-based VMs.
 - Initial iterations may show slightly higher times due to runtime warm-up and optimization overhead, which is common across architectures.  
 - Arm64 demonstrates stable iteration times after the first run, indicating consistent performance for repeated workloads.  
-- Compared to typical x86_64 VMs, Arm64 performance is comparable for lightweight TypeScript computations, with potential advantages in power efficiency and cost for cloud deployments.
+
+This demonstrates that Google Cloud C4A Arm64 virtual machines provide production-grade stability and throughput for TypeScript workloads, whether used for application logic, scripting, or performance-critical services.