You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/typescript-on-gcp/_index.md
+2-3Lines changed: 2 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,13 +7,13 @@ cascade:
7
7
8
8
minutes_to_complete: 30
9
9
10
-
who_is_this_for: This learning path is intended for software developers deploying and optimizing TypeScript workloads on Linux/Arm64 environments, specifically using Google Cloud C4A virtual machines powered by Axion processors.
10
+
who_is_this_for: This is an introductory topic for software developers deploying and optimizing TypeScript workloads on Arm64 Linux environments, specifically using Google Cloud C4A virtual machines powered by Axion processors.
11
11
12
12
learning_objectives:
13
13
- Provision an Arm-based SUSE SLES virtual machine on Google Cloud (C4A with Axion processors)
14
14
- Install TypeScript on a SUSE Arm64 (C4A) instance
15
15
- Validate TypeScript functionality by creating, compiling, and running a simple TypeScript script on the Arm64 VM
16
-
- Benchmark TypeScript performance using a JMH-style custom benchmark with perf_hooks on Arm64 (Aarch64) architecture
16
+
- Benchmark TypeScript performance using a JMH-style custom benchmark with perf_hooks on Arm64 architecture
17
17
18
18
prerequisites:
19
19
- A [Google Cloud Platform (GCP)](https://cloud.google.com/free) account with billing enabled
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/typescript-on-gcp/background.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,6 +18,6 @@ To learn more about Google Axion, refer to the [Introducing Google Axion Process
18
18
19
19
TypeScript is an open-source, strongly typed programming language developed and maintained by Microsoft.
20
20
21
-
It is a superset of JavaScript, which means all valid JavaScript code is also valid TypeScript, but TypeScript adds **static typing, interfaces, and advanced tooling** to help developers write more reliable and maintainable code.
21
+
It is a superset of JavaScript, which means all valid JavaScript code is also valid TypeScript, but TypeScript adds static typing, interfaces, and advanced tooling to help developers write more reliable and maintainable code.
22
22
23
-
TypeScript is widely used for **web applications, server-side development (Node.js), and large-scale JavaScript projects** where type safety and code quality are important. Learn more from the [TypeScript official website](https://www.typescriptlang.org/) and its [handbook and documentation](https://www.typescriptlang.org/docs/).
23
+
TypeScript is widely used for web applications, server-side development (Node.js), and large-scale JavaScript projects** where type safety and code quality are important. Learn more from the [TypeScript official website](https://www.typescriptlang.org/) and its [handbook and documentation](https://www.typescriptlang.org/docs/).
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/typescript-on-gcp/baseline.md
+20-17Lines changed: 20 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,33 +7,33 @@ layout: learningpathall
7
7
---
8
8
9
9
## Baseline Setup for TypeScript
10
-
This guide covers the **baseline setup and testing** of TypeScript on a **Google Axion C4A virtual machine** running SUSE Linux. The objective is to ensure that the TypeScript environment is installed correctly, that basic compilation works, and that a simple TypeScript script can run on the VM.
10
+
This section walks you through the baseline setup and validation of TypeScript on a Google Cloud C4A (Axion Arm64) virtual machine running SUSE Linux.
11
+
The goal is to confirm that your TypeScript environment is functioning correctly, from initializing a project to compiling and executing a simple TypeScript file, ensuring a solid foundation before performance or benchmarking steps.
11
12
12
13
### Set Up a TypeScript Project
13
-
Before testing, we need a project folder with all necessary TypeScript dependencies.
14
+
Before running any tests, you’ll create a dedicated project directory and initialize a minimal TypeScript environment.
14
15
15
-
**1. Create project folder**
16
+
1. Create project folder
16
17
17
-
Create a dedicated folder for your TypeScript project:
18
+
Start by creating a new folder to hold your TypeScript project files:
18
19
19
20
```console
20
21
mkdir ~/typescript-benchmark
21
22
cd ~/typescript-benchmark
22
23
```
23
-
This ensures all files are organized in one place, separate from system files.
24
+
This creates a workspace named `typescript-benchmark` in your home directory, ensuring all TypeScript configuration and source files are organized separately from system files and global modules.
24
25
25
-
**2. Initialize npm project**
26
+
2. Initialize npm project
26
27
27
-
Initialize a Node.js project with default settings:
28
+
Next, initialize a new Node.js project. This creates a `package.json` file that defines your project metadata, dependencies, and scripts.
28
29
29
30
```console
30
31
npm init -y
31
32
```
32
-
The above command creates a `package.json` file, which manages your project dependencies and scripts.
33
33
34
-
**3. Install Node.js type definitions**
34
+
3. Install Node.js type definitions
35
35
36
-
These definitions allow TypeScript to understand Node.js APIs, enabling type checking and code autocompletion.
36
+
To enable TypeScript to properly recognize Node.js built-in APIs (like fs, path, and process), install the Node.js type definitions package:
37
37
38
38
```console
39
39
npm install --save-dev @types/node
@@ -56,9 +56,9 @@ You should see output similar to:
56
56
```
57
57
58
58
### Baseline Testing
59
-
After setting up the project, we perform baseline testing to verify that TypeScript is working correctly on the GCP SUSE VM.
59
+
With the TypeScript environment configured, you’ll now perform a baseline functionality test to confirm that TypeScript compilation and execution work correctly on your Google Cloud SUSE Arm64 VM.
60
60
61
-
**1. Create a Simple TypeScript File**
61
+
1. Create a Simple TypeScript File
62
62
63
63
Create a file named `hello.ts` with the following content:
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/typescript-on-gcp/benchmarking.md
+30-29Lines changed: 30 additions & 29 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,10 +9,11 @@ layout: learningpathall
9
9
10
10
## JMH-style Custom Benchmarking
11
11
12
-
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.
12
+
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.
13
+
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.
13
14
14
15
### Create the Benchmark Script
15
-
Create a file named `benchmark_jmh.ts`in your project folder:
16
+
Create a file named `benchmark_jmh.ts`inside your project directory with the content below:
16
17
17
18
```typescript
18
19
import { performance } from'perf_hooks';
@@ -43,30 +44,34 @@ for (let i = 0; i < iterations; i++) {
43
44
const averageTime =totalTime/iterations;
44
45
console.log(`\nAverage execution time over ${iterations} iterations: ${averageTime.toFixed(3)} ms`);
45
46
```
47
+
Code explanation:
46
48
47
-
-**`performance.now()`** → Provides a high-resolution timestamp in milliseconds for precise timing measurements.
48
-
-**`sumArray`** → A sample CPU-bound function that sums numbers from 0 to `n`.
49
-
-**`iterations`** → Defines how many times the benchmark should run to stabilize results and minimize random variations.
50
-
-**`for` loop** → Executes the target function multiple times and records the duration of each run.
51
-
-**`totalTime / iterations`** → Calculates the **average execution time** across all runs, similar to how **JMH (Java Microbenchmark Harness)** operates in Java.
|**`performance.now()`**| Provides high-resolution timestamps (sub-millisecond precision) for accurate timing. |
52
+
|**`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. |
53
+
|**`iterations`**| Defines how many times the test runs. Multiple repetitions reduce noise and help average out one-off delays or GC pauses. |
54
+
|**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. |
52
55
53
-
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.
56
+
57
+
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.
54
58
55
59
### Compile the TypeScript Benchmark
56
-
Compile the TypeScript benchmark file into JavaScript:
60
+
First, compile the benchmark file from TypeScript to JavaScript using the TypeScript compiler (tsc):
57
61
58
62
```console
59
63
tsc benchmark_jmh.ts
60
64
```
61
-
This generates a `benchmark_jmh.js` file that can be executed by Node.js.
65
+
This command transpiles your TypeScript code into standard JavaScript, generating a file named `benchmark_jmh.js` in the same directory.
66
+
The resulting JavaScript can be executed by Node.js, allowing you to measure performance on your Google Cloud C4A (Arm64) virtual machine.
62
67
63
68
### Run the Benchmark
64
-
Execute the compiled JavaScript file:
69
+
Now, execute the compiled JavaScript file with Node.js:
65
70
66
71
```console
67
72
node benchmark_jmh.js
68
73
```
69
-
You should see an output similar to:
74
+
You should see output similar to:
70
75
71
76
```output
72
77
Iteration 1: 2.286 ms
@@ -85,21 +90,16 @@ Average execution time over 10 iterations: 0.888 ms
85
90
86
91
### Benchmark Metrics Explained
87
92
88
-
-**Iteration times** → Each iteration shows the **time taken for a single execution** of the function being benchmarked.
89
-
-**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**.
90
-
-**Why multiple iterations?**
91
-
- Single-run timing can be inconsistent due to factors such as CPU scheduling, memory allocation, or caching.
92
-
- Repeating the benchmark multiple times and averaging reduces variability and gives **more reliable performance results**, similar to Java’s JMH benchmarking approach.
93
-
**Interpretation:**
94
-
- The average execution time reflects how efficient the function is under normal conditions.
95
-
- Initial iterations may take longer due to **initialization overhead**, which is common in Node.js performance tests.
93
+
* Iteration times → Each iteration represents the time taken for one complete execution of the benchmarked function.
94
+
* 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.
95
+
* Why multiple iterations?
96
+
A single run can be affected by transient factors such as CPU scheduling, garbage collection, or memory caching.
97
+
Running multiple iterations and averaging the results smooths out variability, producing more repeatable and statistically meaningful data, similar to Java’s JMH benchmarking methodology.
98
+
99
+
### Interpretation
96
100
97
-
### Benchmark summary on x86_64
98
-
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:
The average execution time reflects how efficiently the function executes under steady-state conditions.
102
+
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.
103
103
104
104
### Benchmark summary on Arm64
105
105
Results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SUSE):
@@ -108,11 +108,12 @@ 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
111
+
### TypeScript performance benchmarking summary on Arm64
112
112
113
-
When you compare the benchmarking results, you will notice that on the Google Axion C4A Arm-based instances:
113
+
When you look at the benchmarking results, you will notice that on the Google Axion C4A Arm-based instances:
114
114
115
115
- The average execution time on Arm64 (~0.888 ms) shows that CPU-bound TypeScript operations run efficiently on Arm-based VMs.
116
116
- Initial iterations may show slightly higher times due to runtime warm-up and optimization overhead, which is common across architectures.
117
117
- Arm64 demonstrates stable iteration times after the first run, indicating consistent performance for repeated workloads.
118
-
- 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.
118
+
119
+
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.
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/typescript-on-gcp/installation.md
+20-10Lines changed: 20 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,35 +7,44 @@ layout: learningpathall
7
7
---
8
8
9
9
## Install TypeScript on GCP VM
10
-
This page guides you through installing **TypeScript** and its prerequisites on a **GCP SUSE Arm64 VM**. We will install Node.js, npm, TypeScript, and ts-node, and verify that everything works correctly.
10
+
This section walks you through installing TypeScript and its dependencies on a Google Cloud Platform (GCP) SUSE Arm64 virtual machine. You’ll install Node.js, npm, TypeScript, and ts-node, and verify that everything works correctly.
11
+
12
+
Running TypeScript on Google Cloud C4A instances, powered by Axion Arm64 processors, provides a high-performance and energy-efficient platform for Node.js-based workloads.
11
13
12
14
### Update SUSE System
13
-
Before installing new packages, refresh the repositories and update existing packages:
15
+
Before installing new packages, refresh the repositories and update existing ones to ensure your environment is current and secure:
14
16
15
17
```console
16
18
sudo zypper refresh
17
19
sudo zypper update -y
18
20
```
19
-
This ensures that your VM has the latest package information and security updates.
21
+
Keeping your system up to date ensures that dependencies, libraries, and compilers required for Node.js and TypeScript work seamlessly on the Arm64 architecture.
20
22
21
23
### Install Node.js and npm
22
-
Node.js is required to run TypeScript scripts, and npm is the Node.js package manager:
24
+
Node.js provides the JavaScript runtime that powers TypeScript execution, while npm (Node Package Manager) manages project dependencies and global tools.
25
+
26
+
Install both packages using SUSE’s repositories:
23
27
24
28
```console
25
29
sudo zypper install -y nodejs npm
26
30
```
27
-
The above command installs Node.js runtime and npm on your GCP SUSE VM.
31
+
This command installs the Node.js runtime and npm package manager on your Google Cloud SUSE Arm64 VM.
28
32
29
33
### Install TypeScript globally
30
-
TypeScript (`tsc`) compiles `.ts` files to JavaScript, and ts-node allows you to run TypeScript directly without compiling:
34
+
TypeScript (tsc) is the compiler that converts .ts files into JavaScript.
35
+
`ts-node` lets you run TypeScript files directly without pre-compiling them. It is useful for testing, scripting, and lightweight development workflows.
36
+
37
+
Install both globally using npm:
31
38
32
39
```console
33
40
sudo npm install -g typescript ts-node
34
41
```
35
-
- Installing globally (`-g`) makes `tsc` and `ts-node` available in any directory on your VM.
42
+
The `-g` flag installs packages globally, making tsc and ts-node available system-wide.
43
+
44
+
This approach simplifies workflows for developers running multiple TypeScript projects on the same VM.
36
45
37
46
### Verify installations
38
-
Check that Node.js, npm, TypeScript, and ts-node are installed correctly:
47
+
Check that Node.js, npm, TypeScript, and ts-node are all installed correctly:
39
48
40
49
```console
41
50
node -v
@@ -44,7 +53,7 @@ tsc -v
44
53
ts-node -v
45
54
```
46
55
47
-
**Output:**
56
+
The expected output is:
48
57
49
58
```output
50
59
>node -v
@@ -57,4 +66,5 @@ Version 5.9.3
57
66
v10.9.2
58
67
```
59
68
60
-
These version outputs confirm that the Node.js and TypeScript are installed correctly and are ready for development or benchmarking.
69
+
Node.js, npm, and TypeScript are now successfully installed and verified on your Google Cloud C4A (Arm64) virtual machine.
70
+
You’re ready to create and execute TypeScript scripts for testing, deployment, or performance benchmarking.
0 commit comments