RugvAI Labs

Python Internals: CPython, Bytecode & Memory

Python 3.13's free-threaded build (PEP 703) removed the GIL — the biggest change to the runtime in 30 years. Knowing how CPython actually executes bytecode, manages reference counts, and trades the GIL for concurrency is what lets staff engineers reason about why one loop is 10× slower than another. This is the lesson behind every "I made our service 5× faster" blog post.

Learning Objectives

After this lesson, you will be able to:

Trace the full pipeline from .py source file to CPython VM execution
Read and interpret Python bytecode using the dis module
Explain reference counting and when objects are freed from memory
Describe how cyclic GC's three-generation model handles reference cycles
Explain the GIL: why it exists, what it blocks, and how to work around it
Use sys.getsizeof, sys.getrefcount, gc, and tracemalloc for memory insight
Profile Python performance with cProfile and timeit
Choose between CPython, PyPy, and Cython for different workloads

Prerequisites

Before You Start

Review

#How Python Runs Your Code

When you type python script.py, a surprising amount happens before a single line of your logic executes. Python is often called an "interpreted" language, but that's an oversimplification. It's actually compiled to bytecode, which is then executed by a virtual machine.

Here's the full pipeline — click through each stage to see what your code looks like at every step:

Python Execution Pipeline — Source to PVMInteractive

Loading visualization...

#Step 1: Lexing

The lexer reads your source text character by character and breaks it into tokens — the smallest meaningful units. x = 1 + 2 becomes:

NAME 'x'
OP '='
NUMBER '1'
OP '+'
NUMBER '2'
NEWLINE

#Step 2: Parsing → AST

The parser applies Python's grammar rules to the token stream and builds an Abstract Syntax Tree — a tree data structure that represents the logical structure of your code.

pythonrunnable cell

import ast

source = "x = 1 + 2"
tree = ast.parse(source)
print(ast.dump(tree, indent=2))

Output:

Module(
  body=[
    Assign(
      targets=[Name(id='x', ctx=Store())],
      value=BinOp(
        left=Constant(value=1),
        op=Add(),
        right=Constant(value=2)
      )
    )
  ],
  type_ignores=[]
)

The AST is completely language-agnostic at this point. It just describes what operations need to happen, not how.

#Step 3: Compilation → Bytecode

The compiler walks the AST and emits bytecode — a sequence of low-level instructions for CPython's stack-based virtual machine. This bytecode is stored in .pyc files inside __pycache__/.

pythonrunnable cell

import py_compile
py_compile.compile("script.py")
# Creates __pycache__/script.cpython-312.pyc

The .pyc file contains:

A magic number (identifies Python version)
Timestamps/source hash (for cache invalidation)
The marshaled code object (bytecode + constants + names)

Why cache bytecode? Parsing and compiling take time. For large codebases (Django, NumPy), re-compiling on every run would be noticeably slow. Bytecode is cached and reused unless the source changes.

Intuition

Build Your Intuition

The GIL is a revolving door, not a locked gate. Only one person (thread) can pass through a revolving door at a time — but people move through quickly. The GIL lets Python threads share one interpreter safely by taking turns. The key insight is that the door swings open automatically when a thread stands still (waiting for I/O). Three threads downloading files can effectively run at the same time because each one yields the GIL while it waits for the network — they are all standing in the doorway doing nothing, so they might as well let others through.

CPU-bound threads never stand still. They are constantly turning the revolving door themselves, so they truly block each other. This is why threading helps I/O-bound code but not CPU-bound code, and why multiprocessing — which gives each worker their own revolving door — is required for true CPU parallelism in CPython.

Python Bytecode with the `dis` Module

The dis module lets you disassemble Python functions and see the actual bytecode instructions CPython will execute.

pythonrunnable cell

import dis

def add(a, b):
    return a + b

dis.dis(add)

Output:

  2           0 RESUME                   0

  3           2 LOAD_FAST                0 (a)
              4 LOAD_FAST                1 (b)
              6 BINARY_OP               0 (+)
             10 RETURN_VALUE

#Reading the Output

Each line is: line_number offset OPCODE arg (human-readable-arg)

Instruction	Meaning
`LOAD_FAST`	Push a local variable onto the stack
`BINARY_OP`	Pop top two stack items, apply operation, push result
`RETURN_VALUE`	Pop top of stack and return it

CPython is a stack machine — instructions push and pop values from an evaluation stack. There are no registers like in x86 assembly.

#For Loop vs List Comprehension

pythonrunnable cell

import dis

def with_loop(n):
    result = []
    for i in range(n):
        result.append(i * 2)
    return result

def with_comprehension(n):
    return [i * 2 for i in range(n)]

print("=== FOR LOOP ===")
dis.dis(with_loop)

print("\n=== LIST COMPREHENSION ===")
dis.dis(with_comprehension)

The list comprehension generates fewer bytecode instructions and uses a dedicated LIST_APPEND opcode that's more efficient than list.append. Comprehensions also run in their own code object, which keeps the namespace clean.

`a += b` vs `a = a + b`

pythonrunnable cell

import dis

def inplace(a, b):
    a += b
    return a

def regular(a, b):
    a = a + b
    return a

dis.dis(inplace)   # Uses INPLACE_ADD
dis.dis(regular)   # Uses BINARY_OP (Add)

For mutable objects like lists, += calls __iadd__ which modifies in-place (no new object). For immutable objects like integers and strings, both produce identical behavior — CPython falls back to __add__.

#Lambda Bytecode

pythonrunnable cell

import dis

fn = lambda x: x * 2 + 1
dis.dis(fn)
# LOAD_FAST 'x', LOAD_CONST 2, BINARY_OP (*), LOAD_CONST 1, BINARY_OP (+), RETURN_VALUE

A lambda is just a function. Its bytecode is identical to a def function with a single expression body.

x = a + b — step through every bytecode instruction

1 / 9

Source

a = 2
b = 3
x = a + b

Bytecode

Eval stack

LOAD_CONST 2: Push the int 2 onto the evaluation stack.

1 / 9

Every Python operation is a sequence of pushes and pops on this evaluation stack. There are no registers — just one stack and a list of constants/names. That's it. The entire interpreter loop in Python/ceval.c is a giant switch over opcodes that manipulates this stack.

#See the VM run, instruction by instruction

The BytecodeStepper above is great for tracing one snippet. The animated stepper below lets you flip between five canonical scenarios — simple arithmetic, a function call, a branch, a loop, and a tuple-vs-list optimization — and watch the instruction pointer glide across the bytecode while the evaluation stack pushes/pops and locals get bound in real time. Loops literally trace a circle. Jumps draw a curved arrow. That's what your code looks like to the VM.

Loading visualization...

Watch preset E (Tuple vs list) in particular — tuples of constants are folded into a single LOAD_CONST, while lists must be assembled at runtime with three LOAD_CONST + one BUILD_LIST. That's why (1,2,3) is a few times faster to "create" than [1,2,3] — even though they look almost identical in source.

What Do You Think?

What does dis.dis() reveal about Python list comprehensions vs equivalent for loops?

#Reference Counting

Every Python object has an ob_refcnt field — an integer that counts how many references point to it. This is CPython's primary memory management mechanism.

#Rules:

When you assign an object to a variable → refcount +1
When a variable goes out of scope or is reassigned → refcount -1
When refcount reaches 0 → the object is immediately freed

pythonrunnable cell

import sys

x = [1, 2, 3]
print(sys.getrefcount(x))  # 2 (x + the function argument)

y = x  # y also references the same list
print(sys.getrefcount(x))  # 3

del y  # remove y's reference
print(sys.getrefcount(x))  # 2 again

# When x goes out of scope (e.g., function returns), refcount → 0, list is freed

Why +1 from getrefcount? The function call itself creates a temporary reference to the object as an argument. So the refcount is always at least 1 higher than you'd expect.

#Refcount in Action

pythonrunnable cell

import sys

a = "hello"  # refcount = 1 (just 'a')
b = a        # refcount = 2 (a and b)
c = [a, b]   # refcount = 4 (a, b, c[0], c[1])

del a
del b
# refcount is still 2 (c[0] and c[1] still reference it)

del c
# refcount → 0 → string "hello" is freed

#CPython vs Java GC

Feature	CPython (Refcount)	Java (Tracing GC)
Collection trigger	Immediate (refcount = 0)	Periodic / threshold
Pause time	Near-zero (most frees are instant)	Stop-the-world GC pauses
Overhead	Per-operation refcount update	Tracing scan overhead
Cycles	Can't handle (needs cyclic GC)	Handles naturally

Reference counting gives Python deterministic destruction — __del__ is called the moment refcount hits zero (unless there's a cycle).

Loading visualization...

#The Cyclic Garbage Collector

Reference counting has a fatal flaw: circular references.

pythonrunnable cell

a = []
a.append(a)  # a references itself!
# a's refcount is 2 (the variable 'a' + the element a[0])

del a
# The variable 'a' is removed → refcount drops to 1
# But the list still references itself → refcount never reaches 0
# MEMORY LEAK without the cyclic GC!

Python's gc module implements a generational garbage collector specifically for cycles.

#Three Generations

Objects are divided into three generations based on survival:

Gen 0: Newly created objects (collected most often)
Gen 1: Survived one gen-0 collection
Gen 2: Survived one gen-1 collection (collected least often)

The intuition: most objects die young (temporary variables, loop iteration values). Objects that survive are likely long-lived (module-level data, caches). Collecting gen-0 frequently is cheap and catches most garbage.

pythonrunnable cell

import gc

# Check current counts (objects in gen0, gen1, gen2)
print(gc.get_count())  # e.g., (312, 5, 1)

# Thresholds: collect gen-n when count exceeds threshold
print(gc.get_threshold())  # (700, 10, 10) — defaults

# Force a full collection
collected = gc.collect()
print(f"Collected {collected} unreachable objects")

# Check counts again
print(gc.get_count())

#Creating a Cycle

pythonrunnable cell

import gc

class Node:
    def __init__(self, val):
        self.val = val
        self.next = None

# Create a cycle
a = Node(1)
b = Node(2)
a.next = b
b.next = a  # cycle!

del a, b  # refcounts drop but never reach 0

gc.collect()  # cyclic GC finds and frees them

`gc.disable()` for Performance

pythonrunnable cell

import gc

gc.disable()  # Stop automatic cyclic GC
# ... run performance-critical code with no cycles ...
gc.enable()   # Re-enable
gc.collect()  # Manual cleanup

Disabling GC can improve performance by 10-30% in code that creates many objects but no cycles (e.g., pure numerical computation). Libraries like orjson do this internally.

`del` and GC Problems

Objects with __del__ methods that are part of a reference cycle cannot be collected by older Python versions. Python 3.4+ (PEP 442) improved this, but finalizers still add overhead and can delay collection.

pythonrunnable cell

class Problematic:
    def __del__(self):
        print("Being deleted")

a = Problematic()
b = Problematic()
a.ref = b
b.ref = a  # cycle with __del__
del a, b
# Python 3.4+: collected, but in "safe" order determined by GC

Watch Out

Watch out

Fix: Always use == for value comparison. Reserve is only for identity checks against singletons like None, True, and False (if x is None). Never write if x is 1000 or if name is 'alice'.

Using is to compare integers or strings for equality instead of identity, assuming CPython's caching guarantees apply everywhere.

CPython caches small integers (-5 to 256) and automatically interns short identifier-like strings. So `a = 256; b = 256; a is b` returns True, but `a = 257; b = 257; a is b` returns False. This behaviour is a CPython implementation detail, not a language guarantee — PyPy, MicroPython, and future CPython versions may cache different ranges. Code that relies on `is` for value comparison will silently produce wrong results for values outside the cached range and is considered a serious bug in code review.

```python

WRONG: relies on CPython small-int cache

if user_id is 0: return "guest"

RIGHT: explicit value comparison

if user_id == 0: return "guest"

RIGHT: is is fine for singletons

if result is None: raise ValueError("result must not be None") ```

#The GIL (Global Interpreter Lock)

The GIL is one of the most discussed (and misunderstood) features of CPython. It's a mutex — a mutual exclusion lock — that ensures only one thread executes Python bytecode at a time.

#Why Does It Exist?

CPython's reference counting is not thread-safe. Without synchronization, two threads could simultaneously read ob_refcnt, both increment it, and write back — but only one increment would take effect. Objects would be freed prematurely → segfaults.

The GIL is the simplest solution: allow only one thread to run Python code at once. Reference counting is then safe without per-object locks.

#Impact on CPU-Bound Code

pythonrunnable cell

import threading
import time

def count_up(n):
    x = 0
    for _ in range(n):
        x += 1
    return x

# Single thread
start = time.time()
count_up(100_000_000)
print(f"Single thread: {time.time() - start:.2f}s")

# Two threads — same CPU time, no speedup!
start = time.time()
t1 = threading.Thread(target=count_up, args=(50_000_000,))
t2 = threading.Thread(target=count_up, args=(50_000_000,))
t1.start(); t2.start()
t1.join(); t2.join()
print(f"Two threads: {time.time() - start:.2f}s")
# Both take ~the same time — GIL prevents true parallelism

#IO-Bound Code IS Helped by Threading

pythonrunnable cell

import threading
import urllib.request

def fetch(url):
    urllib.request.urlopen(url)  # GIL released during network wait!

# Multiple threads CAN run concurrently for IO
# (the GIL is released when a thread waits for IO)

When a thread makes a system call (disk read, network IO, sleep), it releases the GIL. Other threads can then run Python bytecode. This is why asyncio and threading help with IO-bound workloads.

Loading visualization...

#GIL Release Mechanics

Python 2: Released every 100 bytecode instructions
Python 3.2+: Released every 5ms (configurable via sys.setswitchinterval)
C extensions: Can manually release GIL with Py_BEGIN_ALLOW_THREADS macro (NumPy and SciPy do this for array operations)

pythonrunnable cell

import sys
print(sys.getswitchinterval())  # 0.005 (5ms)
sys.setswitchinterval(0.01)     # Switch every 10ms

#Working Around the GIL

Problem	Solution
CPU-bound parallelism	`multiprocessing` — separate processes, each has its own GIL
IO-bound concurrency	`threading` or `asyncio`
CPU-bound in C	C extensions that release GIL (NumPy, SciPy)
CPU-bound interpreted	PyPy (has its own GIL but faster execution)

#PEP 703: The No-GIL Project

Python 3.13 introduced experimental support for running without the GIL (opt-in). Python 3.14+ may enable it more broadly. The challenge: removing the GIL requires replacing per-refcount updates with atomic operations, and ensuring all C extensions are thread-safe.

#Integer Caching

CPython pre-allocates the integers from -5 to 256 as singleton objects at interpreter startup. These are reused rather than re-allocated.

pythonrunnable cell

a = 100
b = 100
print(a is b)   # True — SAME object in memory
print(id(a) == id(b))  # True

a = 1000
b = 1000
print(a is b)   # True — but NOT because of the small-int cache
print(id(a) == id(b))  # True — `a is b` and id(a) == id(b) are the same test

# Why is it True? Both literals sit in the SAME code object, so the compiler
# stores 1000 once in co_consts and points both names at it. Type these two
# lines one at a time in the REPL and you get False, because each line is
# compiled separately. Never rely on either outcome.

# Build the ints at run time and the dedup cannot happen:
c = int("1000")
d = int("1000")
print(c is d)   # False — two separately allocated objects
print(c == d)   # True  — equal value is the thing you actually wanted

# The small-int cache is different: it survives run-time construction.
print(int("100") is int("100"))   # True — 100 is in the -5..256 range

#Why -5 to 256?

Small integers are used constantly (loop counters, array indices, return codes). Pre-allocating them eliminates repeated malloc/free calls and improves cache locality. The range is an implementation detail of CPython — PyPy may cache more, MicroPython fewer.

#String Interning

Python automatically interns strings that look like identifiers (no spaces, valid variable names):

pythonrunnable cell

a = "hello"
b = "hello"
print(a is b)   # True — interned automatically

a = "hello world"
b = "hello world"
print(a is b)   # True — one shared constant in this code object

Force interning with sys.intern():

pythonrunnable cell

import sys

a = sys.intern("hello world")
b = sys.intern("hello world")
print(a is b)   # True — now interned

When to use sys.intern(): When you have a large lookup table or dictionary with many repeated string keys that are loaded at runtime (not literals). Interning makes is comparison O(1) instead of O(n) character comparison.

The `id()` Function

id(obj) returns the memory address of the object (in CPython). This is how is comparison works internally — a is b is equivalent to id(a) == id(b).

pythonrunnable cell

x = [1, 2, 3]
print(id(x))   # e.g., 140234567890
y = x
print(id(y))   # Same address — same object
z = [1, 2, 3]
print(id(z))   # Different address — new object

#Memory Layout of Python Objects

Every object in CPython is a C struct. At minimum, every Python object has:

typedef struct _object {
    Py_ssize_t ob_refcnt;    // reference count (8 bytes on 64-bit)
    PyTypeObject *ob_type;   // pointer to type object (8 bytes)
} PyObject;

An integer (PyLongObject) adds:

typedef struct {
    PyObject ob_base;        // base PyObject (16 bytes)
    Py_ssize_t ob_size;      // number of digits (8 bytes)
    digit ob_digit[1];       // the actual integer digits
} PyLongObject;

This is why Python objects have overhead compared to C primitives:

pythonrunnable cell

import sys

print(sys.getsizeof(1))         # 28 bytes  (vs 4 bytes for C int32)
print(sys.getsizeof(1.0))       # 24 bytes  (vs 8 bytes for C double)
print(sys.getsizeof(True))      # 28 bytes  (bool inherits from int)
print(sys.getsizeof("hello"))   # 54 bytes  (vs 5 bytes for C char[])
print(sys.getsizeof(""))        # 49 bytes  (empty string overhead)
print(sys.getsizeof([]))        # 56 bytes  (empty list)
print(sys.getsizeof([1,2,3]))   # 88 bytes  (list + 3 pointers)
print(sys.getsizeof((1,2,3)))   # 64 bytes  (tuple is more compact)
print(sys.getsizeof({}))        # 64 bytes  (empty dict)

Note: sys.getsizeof returns the shallow size — it doesn't recursively count the objects that a list's elements point to. Use tracemalloc or the pympler package for deep memory accounting.

#Why This Matters for ML

NumPy's float32 arrays store 4 bytes per element (C floats). A Python list of distinct floats stores 24 bytes per float object plus 8 bytes per pointer in the list. That's 9x more memory overhead for pure Python vs NumPy.

pythonrunnable cell

import sys
import numpy as np

# 1 million floats
# NOTE: [0.0] * 1_000_000 would NOT show this — it makes a million references
# to ONE shared float, so the float overhead is 24 bytes total, not 24 MB.
python_list = [float(i) for i in range(1_000_000)]
numpy_array = np.zeros(1_000_000, dtype=np.float32)

# Rough comparison:
# Python list: ~8MB (pointers) + ~24MB (float objects) = ~32MB
# NumPy float32: 4MB exactly
print(sys.getsizeof(python_list))    # ~8MB for the list container
print(numpy_array.nbytes)            # 4,000,000 bytes = 4MB

This is the core reason to use NumPy for ML: memory efficiency and vectorized C operations with no GIL overhead.

#Python's Memory Allocator (PyMalloc)

Python doesn't call malloc directly for every object allocation. It has a custom allocator, PyMalloc, layered on top of the OS allocator.

#The Three Tiers

Tier 1 (OS):    malloc/free for large allocations (> 512 bytes)
Tier 2 (Arena): Python requests 256KB chunks from the OS
Tier 3 (Pool):  4KB pools carved from arenas, fixed-size blocks

For objects < 512 bytes (which is most Python objects):

Arenas (256KB) are requested from the OS
Each arena is divided into pools (4KB each)
Each pool holds blocks of a single fixed size (8, 16, 24, ..., 512 bytes)
Allocation = find a free block in the right size pool = O(1) + no fragmentation

This is dramatically faster than calling malloc for every tiny object and reduces memory fragmentation.

Memory Profiling with `tracemalloc`

pythonrunnable cell

import tracemalloc

tracemalloc.start()

# --- Code to profile ---
data = [dict(x=i, y=i*2) for i in range(10000)]
# --- End of code ---

snapshot = tracemalloc.take_snapshot()
top_stats = snapshot.statistics("lineno")

print("Top 5 memory allocations:")
for stat in top_stats[:5]:
    print(stat)

Output (example):

Top 5 memory allocations:
profiling.py:6: size=2344 KiB, count=70001, average=34 B
profiling.py:7: size=984 KiB, count=10000, average=101 B

Comparing two snapshots to find leaks:

pythonrunnable cell

import tracemalloc

tracemalloc.start()

snapshot1 = tracemalloc.take_snapshot()

# ... run suspicious code ...
leaky_data = [object() for _ in range(100000)]

snapshot2 = tracemalloc.take_snapshot()
top_stats = snapshot2.compare_to(snapshot1, "lineno")

for stat in top_stats[:5]:
    print(stat)

pythonplayground.py · Pyodide

Tests · assert sys.getsizeof(1) > 0; assert sys.getsizeof([]) < sys.getsizeof([1,2,3])

#Interactive Visualization: CPython Internals Explorer

Step through bytecode execution on a virtual stack machine, see the GIL's thread scheduling, and explore PyMalloc's memory pool hierarchy:

Loading visualization...

#Performance Profiling

`cProfile`: Function-Level CPU Profiling

bash

# Profile a script from the command line
python -m cProfile -s cumulative script.py

# Profile with output to file
python -m cProfile -o output.prof script.py

In code:

pythonrunnable cell

import cProfile
import pstats
import io

def slow_function():
    return sum(i**2 for i in range(100000))

pr = cProfile.Profile()
pr.enable()

slow_function()  # code to profile

pr.disable()
stream = io.StringIO()
ps = pstats.Stats(pr, stream=stream).sort_stats("cumulative")
ps.print_stats(10)  # top 10 functions by cumulative time
print(stream.getvalue())

`timeit`: Micro-benchmarks

pythonrunnable cell

import timeit

# Quick one-liner
print(timeit.timeit("x = [i*2 for i in range(100)]", number=100000))

# Compare two approaches
setup = "data = list(range(1000))"

t1 = timeit.timeit("result = [x*2 for x in data]", setup=setup, number=10000)
t2 = timeit.timeit("result = list(map(lambda x: x*2, data))", setup=setup, number=10000)
t3 = timeit.timeit(
    "import numpy as np; np.array(data) * 2",
    setup="data = list(range(1000))",
    number=10000
)

print(f"Comprehension: {t1:.3f}s")
print(f"map+lambda:    {t2:.3f}s")
print(f"NumPy:         {t3:.3f}s")

#Common Performance Patterns

pythonrunnable cell

# 1. Local variable access is faster than global
import math

def slow():
    result = 0
    for i in range(100000):
        result += math.sqrt(i)  # global lookup each time
    return result

def fast():
    sqrt = math.sqrt           # cache in local variable
    result = 0
    for i in range(100000):
        result += sqrt(i)      # local lookup (faster LOAD_FAST)
    return result

# 2. join() is faster than string concatenation
slow_str = ""
for word in ["hello", "world", "foo", "bar"]:
    slow_str += word   # creates a new string object each time

fast_str = "".join(["hello", "world", "foo", "bar"])  # one allocation

# 3. in operator on set is O(1), on list is O(n)
lookup_set = {1, 2, 3, 1000000}
lookup_list = [1, 2, 3, 1000000]

# Checking membership:
1000000 in lookup_set   # O(1) — hash lookup
1000000 in lookup_list  # O(n) — linear scan

# 4. Avoid repeated dict lookups in inner loops
config = {"key": "value"}
for _ in range(100000):
    val = config["key"]    # dict lookup each time — slow

val = config["key"]        # look up once
for _ in range(100000):
    _ = val                # local variable access — fast

#CPython vs Other Implementations

Implementation	How It Works	Best For	Tradeoffs
CPython	Bytecode interpreter, reference counting	General use, maximum compatibility	Slowest at CPU-bound tasks
PyPy	JIT compiler (traces hot loops, compiles to machine code)	CPU-bound algorithms, long-running processes	Slower startup, higher memory, less C-extension compatibility
Jython	Python → JVM bytecode	Java ecosystem integration	No CPython C extensions, limited Python 3 support
MicroPython	Stripped-down CPython	Microcontrollers (ESP32, Raspberry Pi Pico)	Very limited stdlib
Cython	Compiles `.pyx` files to C extensions

#When to Use PyPy

pythonrunnable cell

# This kind of code benefits enormously from PyPy:
def fibonacci(n):
    a, b = 0, 1
    for _ in range(n):
        a, b = b, a + b
    return a

# CPython: ~2s for fibonacci(10_000_000)
# PyPy: ~0.05s — 40x speedup from JIT compilation

PyPy works best when:

Your code runs a tight loop for a long time (JIT warm-up amortized)
Pure Python (no heavy C extension use)
CPU-bound (GIL is still present in PyPy, but each instruction is faster)

#When to Use Cython

cython

# fibonacci.pyx (Cython)
def fibonacci(int n):
    cdef int a = 0, b = 1
    cdef int i
    for i in range(n):
        a, b = b, a + b
    return a

# Compiled: ~100x faster than CPython for this function
# Used by: NumPy, SciPy, pandas, scikit-learn internals

#Key Takeaways

CPython runs in two phases: source → bytecode (compiler), then bytecode → results (interpreter/ceval loop) — understanding this explains why Python startup is slow but subsequent calls are faster
Reference counting handles most memory immediately: when refcount drops to 0, CPython deallocates the object synchronously — no GC pause; the cyclic collector only runs for reference cycles that refcounting misses
The GIL serializes CPU-bound threads: two threads cannot execute Python bytecode in parallel; use multiprocessing for CPU parallelism or asyncio for I/O concurrency
CPython caches small integers (-5 to 256) and interned strings: a is b can return True for separately created objects in this range — always use == for value comparison, is only for identity
Profile before optimizing: use cProfile to find the actual bottleneck; common wins are algorithmic changes, C extensions (NumPy, Pandas), and switching to PyPy for pure-Python CPU-bound workloads

#Summary

You now understand Python from the inside out:

Layer	Key Concepts
Execution pipeline	`.py` → lexer → tokens → parser → AST → compiler → bytecode → CPython VM
Bytecode	`dis` module, stack machine, LOAD_FAST / BINARY_OP / RETURN_VALUE
Reference counting	`ob_refcnt`, `sys.getrefcount()`, immediate freeing when count = 0
Cyclic GC	Three generations, `gc.collect()`, cycles never freed by refcounting alone
The GIL	One thread runs at a time, released for IO, use multiprocessing for CPU parallelism
Integer caching

Quick Check1 / 5

What does `sys.getrefcount(x)` always return at minimum, even when only one variable references the object?

Your Reflection

Continue Learning

Discussion

Python Internals: CPython, Bytecode & Memory

#How Python Runs Your Code

#Step 1: Lexing

#Step 2: Parsing → AST

#Step 3: Compilation → Bytecode

Python Bytecode with the dis Module

#Reading the Output

#For Loop vs List Comprehension

a += b vs a = a + b

#Lambda Bytecode

x = a + b — step through every bytecode instruction

#See the VM run, instruction by instruction

#Reference Counting

#Rules:

#Refcount in Action

#CPython vs Java GC

#The Cyclic Garbage Collector

#Three Generations

#Creating a Cycle

gc.disable() for Performance

__del__ and GC Problems

#The GIL (Global Interpreter Lock)

#Why Does It Exist?

#Impact on CPU-Bound Code

#IO-Bound Code IS Helped by Threading

#GIL Release Mechanics

#Working Around the GIL

#PEP 703: The No-GIL Project

#Integer Caching

#Why -5 to 256?

#String Interning

The id() Function

#Memory Layout of Python Objects

#Why This Matters for ML

#Python's Memory Allocator (PyMalloc)

#The Three Tiers

Memory Profiling with tracemalloc

#Interactive Visualization: CPython Internals Explorer

#Performance Profiling

cProfile: Function-Level CPU Profiling

timeit: Micro-benchmarks

#Common Performance Patterns

#CPython vs Other Implementations

#When to Use PyPy

#When to Use Cython

CPython's PyObject: The C Struct Behind Every Python Object

#Key Takeaways

#Summary

Python Bytecode with the `dis` Module

`a += b` vs `a = a + b`

`gc.disable()` for Performance

`del` and GC Problems

The `id()` Function

Memory Profiling with `tracemalloc`

`cProfile`: Function-Level CPU Profiling

`timeit`: Micro-benchmarks