Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 3

Execution and Memory in TypeScript, Python, and C#

Recommended resources

Introduction

Welcome to our next lesson. In our previous session, we built a mental map of type systems, distinguishing between static vs. dynamic and strong vs. weak typing. This gave us a framework for understanding a language's rules and predicting its behavior before we even write a line of code. You saw how TypeScript, Python, and C# occupy different spots on this map, which begins to explain the different "feel" of each language.

Today, we move from the abstract rules of a language to the concrete mechanics of how it runs. We'll address the learning outcome of comparing how TypeScript (via Node.js), Python (via CPython), and C# (via .NET) execute code and manage memory. This is a crucial step toward your goal of becoming language-agnostic, as it demystifies why some languages are "fast" for certain tasks and others are "slow," and how they handle the finite resources of a computer. Understanding this is fundamental for any developer aiming for a full-stack and DevOps role where performance and efficiency are paramount.

From Source Code to Machine Instructions

When you write code in a high-level language like TypeScript or Python, the computer's processor can't understand it directly. It must be translated into the processor's native machine code. How this translation happens is a key differentiator between language ecosystems. There are three primary strategies:

  1. Interpretation: A program called an interpreter reads your source code one line or statement at a time and executes it immediately. This offers great flexibility but can be slow, as the translation work happens repeatedly every time the code runs.

  2. Ahead-of-Time (AOT) Compilation: A program called a compiler translates your entire codebase into a standalone executable file of machine code before you run it. This results in very fast execution but can make the development cycle slower. C and C++ are classic examples.

  3. Just-in-Time (JIT) Compilation: This is a hybrid approach that aims for the best of both worlds. Typically, the source code is first compiled into an intermediate, platform-neutral language. Then, at runtime, a component of the language's virtual machine compiles this intermediate code into native machine code "just in time" to be executed. This allows for powerful optimizations based on how the code is actually being used.

As you'll see, the three languages we're focusing on each lean on a different combination of these strategies.

A Tale of Three Runtimes

Let's examine how TypeScript, Python, and C# each approach execution and memory management.

TypeScript (via Node.js and the V8 Engine)

As you know from your experience, TypeScript code doesn't run directly. It's first transpiled into JavaScript. Therefore, when we talk about executing TypeScript in a backend context, we're really talking about how the Node.js runtime executes the resulting JavaScript.

  • Execution: Node.js uses Google's V8 engine, the same one found in Chrome. V8 is a masterpiece of JIT compilation. When it receives JavaScript code, it doesn't just interpret it. Initially, an interpreter (called Ignition) starts executing the code. Simultaneously, V8's profiler watches the code run. If it identifies functions or loops that are executed frequently (so-called "hot paths"), it passes them to its optimizing JIT compiler (called TurboFan). TurboFan compiles that code into highly optimized, native machine code for maximum speed. This is why a Node.js application might start a little slower but can achieve excellent performance for long-running processes.

  • Memory Management: V8 manages memory automatically using a sophisticated garbage collector (GC) called Orinoco. It's a tracing garbage collector. In simple terms, it starts from a set of known "roots" (like global variables and the current call stack) and traces every object they can reach. Any object it can't reach is considered garbage and its memory is reclaimed. To be efficient, it's also a generational collector, meaning it assumes that most objects "die young." New objects are placed in a "young generation" space which is collected frequently. Objects that survive a few collections are promoted to an "old generation" space, which is checked less often.

C# (via .NET and the CLR)

C#'s model is a very refined and formalized version of the JIT compilation strategy.

  • Execution: Your C# code is first compiled into Common Intermediate Language (CIL), which is stored in files called assemblies (.exe or .dll). CIL is similar in concept to Java's bytecode. When you run your program, the Common Language Runtime (CLR) loads this CIL. The CLR's JIT compiler then converts the CIL into native machine code that your CPU can execute.

Take a look at this flowchart, which visualizes the entire process from development to execution.

This flowchart illustrates the key steps in running C# code. The process begins with the developer writing code, which is then compiled into an Intermediate Language (IL). The Common Language Runtime (CLR) loads this IL and uses a Just-in-Time (JIT) compiler to convert it into native machine code for execution. The CLR also handles crucial runtime services like memory management and exception handling.

As you can see, the JIT compilation step is a distinct, mandatory part of the execution flow. This model allows C# code to be portable (any OS with a .NET runtime can execute the CIL) while still achieving near-native performance.

  • Memory Management: As the flowchart shows, the CLR is responsible for managing memory. Like V8, it uses an automatic, tracing, generational garbage collector. It's highly optimized to be fast and efficient, automatically handling the allocation and deallocation of memory for your objects on the managed heap.

Python (via CPython)

Python's most common implementation, CPython, has a traditionally simpler model, though with some important details.

  • Execution: When you run a Python script, the CPython interpreter first compiles your source code into bytecode. This bytecode is a simpler, platform-independent representation of your program. If it can, CPython will save this bytecode to disk in .pyc files so it can skip the compilation step on subsequent runs. Then, the Python Virtual Machine (PVM) proceeds to interpret this bytecode. It reads each bytecode instruction and executes the corresponding C code within the interpreter. This interpretation step, which happens every time the code is run, is a key source of Python's relative slowness for CPU-intensive tasks.

  • Memory Management: CPython's primary memory management strategy is automatic reference counting. Every object in memory has a counter. When a new reference to an object is made (e.g., y = x), its count is incremented. When a reference is destroyed (e.g., a variable goes out of scope), its count is decremented. When the count reaches zero, the object's memory is immediately freed.

This is simple and deterministic, but it has a critical weakness: cyclic references. This happens when two or more objects refer to each other.

This diagram illustrates a cyclic reference. Two `Node` objects point to each other. Even after the external variables (`node1`, `node2`) are deleted, the objects' reference counts remain at 1 because they still refer to each other. A simple reference counting garbage collector cannot reclaim this memory, leading to a leak.

As the image shows, even when we delete the node1 and node2 variables, the two node objects still have a reference count of 1 because they point to each other. They are now unreachable, but their memory won't be freed. To solve this, CPython has a secondary, periodic cycle detector. This is a tracing garbage collector (like in V8 and .NET) that runs occasionally to find and clean up these unreachable cycles.

Putting It All Together: Performance and Trade-offs

Now that you understand the different execution models, you can begin to understand their practical consequences for performance. A very insightful article explores this by comparing the energy consumption of C#, Python, and Node.js for CPU-heavy tasks. The underlying reasons are exactly what we've just discussed.

Tech Insights & Success Stories Blog | Managed Code | C# vs Python Energy Consumption on Hot Paths

This article directly connects the runtime models we've discussed to real-world performance and efficiency. It explains why these differences emerge in a clear, practical way.

First, read the section Why do they lose on hot paths?. Pay close attention to the explanations for Python's "interpretation overhead" and the discussion of Node.js's model being optimized for I/O, not CPU-bound work. Next, read the crucial caveats in the section Where the hardline version breaks. This provides essential nuance, showing that the "best" language is always context-dependent.

As you've just read, the trade-offs become clear:

  • Python (CPython) is penalized by its interpretation overhead. For code that involves tight loops and heavy computation, the interpreter is doing the same work of decoding bytecode again and again. However, when Python is just "gluing" together high-performance libraries written in C or Fortran (like NumPy or Pandas), this penalty becomes negligible.

  • TypeScript/Node.js (V8) is optimized for I/O-bound tasks. The event loop model is incredibly efficient at handling many concurrent connections, database queries, or file reads. But if you block that single main thread with a long-running, CPU-intensive calculation, the entire application grinds to a halt. The solution (worker threads) adds complexity, admitting the model isn't ideal for that job.

  • C# (.NET), with its robust JIT compilation to native code, excels at CPU-bound workloads. The initial compilation cost is paid once, and after that, the code runs at or near native speed. This makes it a strong choice for services that perform complex calculations, simulations, or data processing.

Conclusion

In this lesson, we've peered under the hood to see how our code actually runs. You now have a mental model for comparing the execution and memory management strategies of three major ecosystems.

  • Key Takeaway 1: Execution strategies form a spectrum. Python's CPython interpreter is at one end, while C# and Node.js's V8 use sophisticated JIT compilers that turn hot code into fast, native machine instructions.
  • Key Takeaway 2: Memory management is automatic in all three, but the mechanisms differ. CPython uses primarily reference counting with a backup cycle detector, while .NET and V8 use more advanced tracing garbage collectors.
  • Key Takeaway 3: These architectural decisions create clear trade-offs. C#'s model is optimized for computational performance. Node.js is optimized for I/O concurrency. Python is optimized for developer productivity and as a "glue" language, but can be slow for pure-Python computation.

Understanding these fundamentals is a huge leap toward being able to "step in at any stage of the process." You can now look at a task and make an informed guess about which language and runtime would be a good fit, based not on syntax, but on deep, architectural principles.

In our next lesson, we will get even more practical with memory. We'll move beyond the high-level garbage collection models and trace the difference between stack and heap allocation using small code snippets in both TypeScript and Python. This will give you a hands-on feel for how data is organized in memory during a program's execution.