Memory Optimization & Concurrency / the GIL

Why this matters for agents motivation

Here's the failure that ends most people's first "real" AI deployment. Your prototype was flawless — it embedded a few hundred documents, answered questions in a blink, handled you and a colleague clicking around. So you point it at the full corpus and open it to the team, and within an hour it's either dead (the process got killed with a cryptic MemoryError or vanished silently to an OOM reaper) or crawling (users wait thirty seconds because everyone is queued behind one request at a time). Nothing in your logic was wrong. What changed was scale — and scale is exactly where the two invisible costs in this chapter, memory and concurrency, stop being invisible.

Think of it like moving from cooking dinner for yourself to running a restaurant kitchen. At home you never think about counter space or whether you can chop and simmer at the same time — there's plenty of room and only one order. A restaurant on a Friday night is a different universe: you run out of counter space (memory) and you have forty tickets that all need to happen at once (concurrency). The recipes didn't change; the constraints did. Every AI system makes this same jump, and the engineers who anticipate it ship things that stay up.

The common mistake is to treat both as someone else's problem — "the cloud has infinite RAM," "I'll just add more servers." That's the expensive path, and it papers over bugs rather than fixing them. A million 1024-dimension float32 embeddings is genuinely 4 GB; if you store it as a Python list of lists you'll pay several times that and OOM on a box that should have fit it. An agent that makes one 2-second API call per user handles thirty users a minute if it works sequentially — or hundreds, on the same machine, if you let those waits overlap. This part teaches you to see those costs before production does, so you tune the code instead of the invoice.

A RAG index of a million 1024-dim float32 embeddings is 4 GB — store it wrong and you OOM. An agent serving 100 concurrent users making 2-second API calls needs concurrency or it handles one user at a time. Get memory and concurrency right and the same laptop or box handles 10× the load; get them wrong and you scale by throwing money at servers.

1 · How Python objects use memory intermediate

Quick gut-check: how many bytes do you think the number 0 takes in Python? If you said "8, it's a 64-bit integer" — reasonable guess, and wrong by a factor of three and a half. It's about 28 bytes. That gap is the single most important thing to internalize in this section, because when you multiply it across a million rows it turns a "surely this fits in RAM" into an out-of-memory crash.

Here's the why, in plain terms. In a language like C, an int is just the raw 8 bytes of the number sitting in memory — nothing else. Python trades that leanness for enormous flexibility: every value, even a lowly integer, is a full-blown object, and every object drags a little backpack of bookkeeping around with it. Inside that backpack are a reference count (how many things currently point at me, so Python knows when to free me), a type pointer (am I an int? a str? a Model?), and for ordinary class instances a whole per-object __dict__ to hold attributes. The number is in there somewhere, but it's wearing a heavy coat.

A useful analogy: a raw value is a bare book, but a Python object is that book fully catalogued in a library — barcode, shelf location, checkout card, dust jacket. One book, you don't notice the overhead. A million books and the catalogue cards alone fill a room. The flexibility is real and worth it (this is why you can put anything in a list and ask any object its type at runtime), but it is never free, and the cost hides until scale reveals it.

The mistake this leads to is guessing instead of measuring. Engineers eyeball "a list of a million ints, that's 8 MB, fine" and are shocked when it's 30–40 MB, because a list holds a million 8-byte pointers and the million int objects those pointers reach. The discipline that saves you is simple: don't reason about Python memory from first principles, weigh it. Python ships two scales — sys.getsizeof for the size of a single object, and tracemalloc for tracking where allocations actually pile up across your whole program. The lab below puts a few "small" values on the getsizeof scale so the overhead stops being abstract.

Every Python object carries overhead: a reference count, a type pointer, and (for normal classes) a per-instance __dict__. A "small" object is rarely small. Measure, don't guess — with sys.getsizeof and tracemalloc.

pythonimport sys

print(sys.getsizeof(0))          # ~28 bytes for a single int!
print(sys.getsizeof(""))         # ~49 bytes empty str
print(sys.getsizeof([]))         # ~56 bytes empty list (+ 8/elem pointer)
print(sys.getsizeof({}))         # ~64 bytes empty dict

# A million ints in a list: pointers + the int objects themselves
# -> use array/numpy for homogeneous numeric data (see below & A4)

2 · __slots__ — drop the per-instance dict advanced

You just learned that a plain instance carries a whole hash table for its attributes. Now imagine you have five million of them. That's not a hypothetical — it's a graph with five million nodes, a parsed log with five million events, a corpus chunked into five million records. Suddenly the invisible __dict__ tax on each object is the difference between fitting in memory and not. __slots__ is the one-line declaration that turns that tax off.

Why does it work? By default, when you write self.text = "hi", Python stashes that attribute in a per-instance __dict__ — a full hash table living inside every single object. Hash tables are wonderful when you don't know the keys ahead of time (you can bolt on any attribute you like at any moment), but they're bulky: buckets, spare capacity, hashing machinery. The catch is that for a class like a data record, you do know the attributes in advance — they're always text and vec, never anything else. Declaring __slots__ = ("text", "vec") hands Python that promise, and in exchange Python stores the values in a tight fixed-size array baked directly into the object, with no dict at all.

Picture the difference as filing cabinets versus a fitted tray. A __dict__ is a filing cabinet with room for folders you might add later — roomy, general, heavy. __slots__ is a custom foam tray cut to hold exactly two tools: no wasted space, and you grab each tool faster because its position is fixed. That "grab faster" is a real bonus — slotted attribute access is a bit quicker too, since it's a direct array offset instead of a hash lookup.

The mistake people make is reaching for __slots__ everywhere, as a reflex "optimization," and then getting bitten. The whole deal is that you gave up flexibility: a slotted object cannot grow a new attribute you didn't declare (obj.extra = 5 raises AttributeError), and slots interact awkwardly with multiple inheritance. So the rule is narrow and specific — use it for the classes you stamp out in bulk (nodes, cache entries, records, events), and don't bother for the handful of config or singleton objects where the memory is irrelevant and the freedom is handy. The lab measures the dict you're deleting, so the payoff is concrete rather than a claim.

By default each instance has a __dict__ (a whole hash table) to hold attributes — flexible but heavy. Declaring __slots__ tells Python the fixed attribute set, so it stores them in a compact array instead: big memory savings and faster access when you have many instances (nodes, records, events).

pythonclass ChunkA:                     # normal: has __dict__
    def __init__(self, text, vec):
        self.text, self.vec = text, vec

class ChunkB:
    __slots__ = ("text", "vec")       # no per-instance dict
    def __init__(self, text, vec):
        self.text, self.vec = text, vec

import sys
a, b = ChunkA("x", 1), ChunkB("x", 1)
print(sys.getsizeof(a.__dict__))     # ~100+ bytes just for the dict
# ChunkB has no __dict__ at all -> across millions of chunks, huge savings

3 · Buffers & zero-copy — memoryview, bytearray, array, struct expert essential

Every time you slice a big blob of bytes, Python quietly makes a full copy of that slice — and if you do it in a loop, you can copy gigabytes without writing a single line that says "copy." That's the hidden cost this section kills. When you're shuffling model weights, embedding blobs, or network frames — payloads measured in megabytes — the copying can easily cost more than the actual work you meant to do.

The idea that fixes it is copy versus view, and it's worth slowing down on because it underpins how numpy, PyTorch, and every fast numeric library work. A copy duplicates the data into fresh memory; a view is a window that points into the original memory and reads/writes straight through it. Think of a copy as photocopying ten pages of a book to mark them up, versus a view as laying a transparent sticky-flag over those same pages — the flag adds nothing, and anything you write on it is really written on the page underneath. A memoryview is that sticky flag: it exposes another object's buffer with zero copying, in O(1) time and 0 extra bytes.

Alongside memoryview, this section brings in three companions that all attack the same "objects are heavy, copies are expensive" problem from different angles. bytearray is a mutable block of raw bytes you can write into (plain bytes is read-only). array stores a run of homogeneous numbers as raw values with no per-element object overhead — a million floats in ~4 MB instead of the ~30+ MB a list of float objects would cost (this is exactly the object-overhead tax from §1, paid once instead of a million times). And struct packs and unpacks fixed binary layouts, which is how you read a wire-protocol header or a binary file format byte-for-byte.

The mistake to watch for is the flip side of the superpower: because a memoryview shares memory with its parent, writing through the view mutates the original — surprising if you thought you were working on a private copy — and a view keeps the underlying buffer alive, so you can accidentally pin a huge object in memory just by holding a tiny window into it. That's a fair trade once you know it's happening. The lab makes the sharing visible: it writes one byte through a slice and shows the giant buffer changed underneath.

Slicing bytes or a list copies data (D1). For large binary/numeric payloads — model weights, embedding blobs, network frames — copies dominate. A memoryview exposes another object's buffer without copying; array stores homogeneous numbers compactly; struct packs/unpacks binary formats.

pythonimport array

# memoryview: slice a big buffer with NO copy
data = bytearray(10 * 1024 * 1024)   # 10 MB
view = memoryview(data)
chunk = view[1024:2048]              # a window, not a copy — O(1), 0 bytes extra
chunk[0] = 255                        # writes straight through to `data`

# array: a million floats WITHOUT per-element object overhead
scores = array.array("f", [0.0] * 1_000_000)   # ~4 MB, vs ~30+ MB in a list

# struct: pack/unpack a binary record (e.g. a wire protocol header)
import struct
packed = struct.pack(">IHf", 42, 7, 3.14)   # big-endian: uint32, uint16, float
n, k, x = struct.unpack(">IHf", packed)

4 · Garbage collection & weakref advanced

Your agent has been running fine for three days, and then it dies at 3 a.m. with the RAM graph a perfect diagonal line climbing to the ceiling. No crash bug, no bad request — just memory that went up and never came back down. That's a leak, and understanding how Python reclaims memory is what lets you find it. The good news is Python usually cleans up after you automatically; the trap is the handful of cases where it can't, and those cases are exactly what long-running agents hit.

Python's main cleanup mechanism is delightfully simple: reference counting. Every object keeps a tally of how many things currently point at it. Assign it somewhere, the count goes up; the variable goes out of scope or you del it, the count goes down. The instant that tally hits zero — nobody is holding this anymore — the object is freed immediately. It's like a coat-check that throws away a coat the moment the last claim ticket for it is handed back. This is why memory in Python typically frees itself the second you stop using something, with no pause and no separate "collector" running.

But counting alone has one blind spot, and it's the classic one: reference cycles. Suppose object A holds a reference to B, and B holds one right back to A. Even after you let go of both, each still has a count of 1 — because they're pointing at each other — so neither ever reaches zero, and neither is ever freed. Two friends each refusing to leave the party until the other does. To handle this, CPython runs a second, periodic cyclic garbage collector that hunts down these islands of mutually-referencing junk and reclaims them. You can nudge it with gc.collect(), but mostly it just works in the background.

The third tool, weakref, is the subtle one, and it's the fix for the most common agent leak. A normal reference is a strong claim — "keep this alive as long as I exist." Sometimes you want the opposite: to refer to an object without being the reason it stays in memory. That's a weak reference. The textbook case is a cache: you want to remember a Model object if it's still in use elsewhere, but you emphatically do not want your cache to be the thing keeping every model that ever passed through alive forever. Hold cache values weakly and they evaporate the moment their last real user lets go — no leak. The mistake this section is really warning against is the opposite: an ever-growing global list or dict that you append to and never trim. Reference counting can't save you there, because you are still holding a live strong reference to every item — the leak is working as coded. The lab shows a weakref cache emptying itself, and the callout names the global-collection leak so you'll recognize it in the wild.

CPython frees objects mainly by reference counting — when the last reference goes away, the object is freed immediately. A separate cyclic garbage collector handles reference cycles (A→B→A) that counting alone can't. A weak reference lets you refer to an object without keeping it alive — essential for caches that shouldn't cause leaks.

pythonimport weakref, gc

class Model:
    def __init__(self, name): self.name = name

# A cache that does NOT keep models alive on its own
cache = weakref.WeakValueDictionary()
m = Model("opus")
cache["opus"] = m
del m                     # last strong ref gone -> entry auto-disappears
print(list(cache))        # [] — no leak

# Cycles need the GC (or manual breaking):
gc.collect()              # force a cyclic-GC pass; returns objects collected

5 · The GIL — what it actually is expert intermediate

Ask ten Python developers what the GIL does and you'll get "it makes Python slow" or "it means threads don't work" — and both are wrong enough to make you write bad code. This is the single most misunderstood mechanism in the language, and getting it precisely right is what lets you choose threads, processes, or async on purpose instead of by folklore. So let's define it exactly, then dismantle the myth.

The Global Interpreter Lock is a single lock (a mutex) inside a CPython process, and the rule it enforces is narrow: only one thread may be executing Python bytecode at any given instant. A thread must hold this one lock to run your Python code, and there's only one lock, so no matter how many threads you spawn, exactly one is running Python at a time. Picture an open-plan kitchen with a dozen cooks but only one chef's knife — everyone can be busy prepping, plating, or waiting on the oven, but only one person can actually be cutting at once, and they have to pass the knife around.

Why on earth would the language do this? Because of §4's reference counting. Every object's refcount is being incremented and decremented constantly, and if two threads bumped the same count at the same time, the counts would corrupt and Python would free objects that are still in use — instant crashes. The GIL is the cheap, brute-force fix: make bytecode execution single-threaded and the counts can never race. It bought CPython simplicity and speed for the overwhelmingly common single-threaded case, at the price of true multi-core Python threading.

Now the myth, and the nuance that demolishes it. The knife is only held while a cook is actually cutting — the moment a thread stops running Python bytecode, it hands the GIL back. And threads stop running Python constantly: whenever they wait on the network or disk (an I/O syscall isn't Python bytecode), and whenever they drop into a C extension that explicitly releases the lock — numpy's math loops, compression, crypto, and the like. So the honest statement is not "threads don't work." It's: threads give you no speedup for CPU-bound pure-Python code, but they absolutely help when your threads spend their time waiting or inside C. That single distinction — is my bottleneck waiting, or is it pure-Python computing? — decides everything in the next three sections, and the table plus the labs make it concrete. (One caveat worth knowing: Python 3.13+ ships an experimental free-threaded build that removes the GIL entirely, but it's opt-in and not yet the default, so assume the GIL is present unless you've deliberately turned it off.)

The Global Interpreter Lock is a mutex that lets only one thread execute Python bytecode at a time in a CPython process. It exists to make memory management (reference counting) safe without per-object locks. The consequence everyone half-remembers: threads don't give you CPU parallelism for pure-Python code. But the crucial nuance: the GIL is released during I/O (network, disk) and inside many C extensions (numpy, compression, crypto).

6 · Threads — for I/O-bound fan-out advanced

Your agent needs to fetch ten documents, and each fetch takes one second. Done one after another, that's ten seconds your user stares at a spinner. Done right, it's one second. The trick isn't a faster network — it's noticing that for nine of those ten seconds, your program was doing nothing but waiting. Threads let those waits happen on top of each other, and for the I/O-bound work that dominates agent code, that's the highest-leverage change you can make.

This is where §5's nuance pays off directly. A network call spends almost all its time blocked on a syscall — not running Python bytecode — so the GIL is released the whole time it waits. That means a second thread can fire off its request while the first is still waiting for a reply, and a third while those two wait, and so on. It's a restaurant server taking a second table's order while the first table's food cooks: the cooking (the network round-trip) overlaps, and total wall-clock time collapses toward the length of the single slowest wait rather than the sum of all of them.

The clean way to express this is a thread pool — you don't hand-manage threads, you hand jobs to a pool and collect the results. concurrent.futures.ThreadPoolExecutor is that interface: you submit work and get back futures (placeholders for results that aren't ready yet), or map a function over inputs, and the pool runs up to max_workers of them concurrently. The with block tidies the threads away when you're done. The common mistake beginners make here is expecting this same pattern to speed up a heavy math loop — it won't, because that's pure-Python CPU work where the GIL is held the entire time and the threads just take turns. Threads are for waiting, not computing; keep that line bright. The lab shows ten one-second fake fetches finishing in about one second, and invites you to throttle max_workers to watch the overlap shrink.

Since the GIL releases during network waits, threads are a simple way to make many API calls concurrently. ThreadPoolExecutor is the clean interface.

pythonfrom concurrent.futures import ThreadPoolExecutor, as_completed
import time

def fetch(doc_id):
    time.sleep(1)              # stand-in for a network/API call (GIL released)
    return (doc_id, f"content-{doc_id}")

ids = range(10)
# Sequential: ~10s.  With 10 threads: ~1s — because they wait in parallel.
with ThreadPoolExecutor(max_workers=10) as ex:
    futures = [ex.submit(fetch, i) for i in ids]
    results = [f.result() for f in as_completed(futures)]
print(len(results))          # 10, in ~1 second

7 · Processes — for CPU-bound work advanced

So threads collapsed ten seconds of waiting into one — but what if your ten jobs aren't waiting at all? What if each one is a grinding pure-Python calculation with no network in sight? Then threads give you exactly nothing: the GIL hands the knife around, one cook cuts at a time, and your eight-core machine runs at the speed of one core. To actually use all those cores for Python computation, you need to stop sharing a GIL — and the way to do that is to stop sharing an interpreter.

That's what a process is. Each operating-system process gets its own private Python interpreter, its own memory, and — the whole point — its own separate GIL. Four processes on a four-core box genuinely run four Python computations at the same instant, because there are now four knives, one per kitchen. This is the only way to get true multi-core parallelism out of CPU-bound pure Python, and concurrent.futures.ProcessPoolExecutor gives you the same tidy submit/map interface you already learned for threads — you often change one word to switch models.

But separate memory is a double-edged sword, and this is where the mistakes cluster. Because processes share nothing, any input you send and any result you get back must be pickled (serialized to bytes), shipped across a pipe, and unpickled on the other side — a real cost that scales with your data. So processes pay off only when the compute per job dwarfs that copying overhead; hand a process pool a pile of tiny jobs and the pickling can cost more than you saved. The second classic trap is platform-specific: on macOS and Windows, new processes start by re-importing your script, so without the if __name__ == "__main__": guard, the pool tries to launch a pool that tries to launch a pool — an infinite fork bomb. The lab runs four genuinely heavy jobs across cores and then dares you to swap in ThreadPoolExecutor and watch it stay stubbornly slow — the GIL, demonstrated in your own terminal.

To actually parallelize CPU-bound Python, use separate processes — each has its own interpreter and its own GIL, so they run truly in parallel on multiple cores. The cost: data must be pickled and copied between processes, so it's worth it only when the compute per item dwarfs that overhead.

pythonfrom concurrent.futures import ProcessPoolExecutor

def heavy(n):                 # pure-Python CPU work — threads would NOT parallelize this
    return sum(i*i for i in range(n))

if __name__ == "__main__":      # required guard on Windows/macOS spawn
    with ProcessPoolExecutor() as ex:      # defaults to #CPU cores
        results = list(ex.map(heavy, [10_000_000] * 4))
    # 4 cores -> ~4x faster than sequential for this CPU-bound task

8 · Choosing a concurrency model intermediate

Here's the whole chapter compressed into one decision you'll make on real systems: given a workload, do you reach for asyncio, threads, or processes? Pick wrong and you either leave your cores idle or drown a simple task in overhead. The reassuring news is that the choice is almost mechanical once you ask the right question first — and that question is always the same.

Ask: is this job spending its time waiting, or computing? That one distinction, which you met with the GIL and saw proven in the last two labs, sorts nearly everything. If the bottleneck is waiting — on the LLM API, a database, a file, another service — you want a concurrency model that overlaps waits, and you never need real CPU parallelism because the CPU is idle anyway. If the bottleneck is computing in pure Python, you need genuine multi-core parallelism, which means processes (or pushing the math into a C library like numpy that drops the GIL for you).

Within the "waiting" branch there's a second, finer choice, and it's about scale, not capability. Threads are the low-ceremony option: they share memory, the code reads like ordinary blocking code, and they're perfect for moderate fan-out — a few dozen concurrent calls. But each OS thread costs real memory and scheduling overhead, so when you need thousands of simultaneous waits (a server juggling ten thousand open connections), asyncio wins decisively because it does it all in one thread with tiny per-task cost — at the price of "async all the way down" plumbing (that's chapter A3). The common mistake is treating these as rival religions to argue about; they're tools matched to a bottleneck. The frequent right answer in a real agent is to combine them — threads or async to fan out the I/O, a process pool for the occasional heavy compute — which is exactly what the practice-ladder solution below does. Use the table as your cheat sheet, but carry the question, not the grid.

Exercises advanced

🎯 Interview practice interview

The interview questions this topic gets asked — worked, with code. For the full pattern catalog see A9 · Big Tech AI-engineering patterns.

class _Any:
    '''stands in for any undefined demo value; supports call/attr/index/
    iteration and basic arithmetic (as 0.7) so demo snippets run.'''
    def __call__(self, *a, **k): return _Any()
    def __getattr__(self, k): return _Any()
    def __getitem__(self, k): return _Any()
    def __iter__(self): return iter([])
    def __len__(self): return 0
    def __contains__(self, o): return True
    def __enter__(self, *a): return _Any()
    def __exit__(self, *a): return False
    def __float__(self): return 0.7
    def __int__(self): return 1
    def __lt__(self, o): return True
    def __gt__(self, o): return False
    def __le__(self, o): return True
    def __ge__(self, o): return False
    def __add__(self, o): return o
    def __radd__(self, o): return o
    def __bool__(self): return True
    def __repr__(self): return 'demo'
    def __str__(self): return 'demo'
urls = _Any()

pythonfrom concurrent.futures import ThreadPoolExecutor
# I/O-bound: 10 network calls overlap because the GIL is released on I/O
def fetch(url): ...            # network wait
with ThreadPoolExecutor(max_workers=10) as ex:
    results = list(ex.map(fetch, urls))   # ~1x latency, not 10x

pythonclass Point:
    __slots__ = ("x", "y")    # no per-instance dict -> big savings at scale
    def __init__(self, x, y): self.x, self.y = x, y

def squares(n):
    for i in range(n):        # generator: O(1) memory, not O(n)
        yield i * i

Checkpoint advanced

import sys

class Point:
    def __init__(self, x, y):
        self.x = x; self.y = y

p = Point(1, 2)
print("instance dict:", p.__dict__)                 # {'x': 1, 'y': 2}
print("dict size (bytes):", sys.getsizeof(p.__dict__))
print("object header:", sys.getsizeof(p))

class Dictful:
    def __init__(self, x, y):
        self.x = x; self.y = y

class Slotted:
    __slots__ = ("x", "y")
    def __init__(self, x, y):
        self.x = x; self.y = y

d = Dictful(1, 2)
s = Slotted(1, 2)
print(hasattr(d, "__dict__"))   # True
print(hasattr(s, "__dict__"))   # False
try:
    s.z = 3                       # slots forbid new attrs
except AttributeError as e:
    print("blocked:", e)

buf = bytearray(b"HELLO world")
mv = memoryview(buf)

word = mv[6:11]          # view, NOT a copy
word[:] = b"WORLD"       # writes straight into buf
print(buf)               # bytearray(b'HELLO WORLD')

copy = bytes(buf[0:5])   # bytes slice IS a copy
print(copy)              # b'HELLO'
print(mv.nbytes, "bytes viewed with no copy")

import weakref, gc

class Doc:
    def __init__(self, name):
        self.name = name

cache = weakref.WeakValueDictionary()
d = Doc("a")
cache["a"] = d
print("a" in cache)     # True

del d                    # drop the only strong ref
gc.collect()
print("a" in cache)     # False -- entry auto-removed

import time
from concurrent.futures import ThreadPoolExecutor, ProcessPoolExecutor

def work(n):
    s = 0
    for i in range(n):
        s += i * i
    return s

N, TASKS = 2_000_000, 4

if __name__ == "__main__":       # required for ProcessPool
    t = time.perf_counter()
    with ThreadPoolExecutor(4) as ex:
        list(ex.map(work, [N]*TASKS))
    print("threads:  %.2fs" % (time.perf_counter()-t))

    t = time.perf_counter()
    with ProcessPoolExecutor(4) as ex:
        list(ex.map(work, [N]*TASKS))
    print("processes: %.2fs (faster on multi-core)" % (time.perf_counter()-t))

from concurrent.futures import ThreadPoolExecutor, ProcessPoolExecutor

def fetch(url):                     # I/O-bound (needs network to run)
    # response = requests.get(url); return response.text
    return f"stub:{url}"

def score(vec):                     # CPU-bound stand-in
    return sum(x*x for x in vec)

def handle(urls, vectors):
    with ThreadPoolExecutor(16) as io:      # overlap network waits
        docs = list(io.map(fetch, urls))
    with ProcessPoolExecutor(4) as cpu:     # real parallel math
        scores = list(cpu.map(score, vectors))
    return docs, scores

if __name__ == "__main__":
    d, s = handle(["a", "b"], [[1,2,3], [4,5,6]])
    print(d, s)                     # ['stub:a','stub:b'] [14, 77]

Knowledge check check yourself