🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🎒 धडा 05 — Memory: सगळे अडथळे एकदम, की एका वेळी एक?

📍 तुम्ही इथे आहात: 12 पैकी धडा 05 · मागे: lesson-04-complexity · पुढे: lesson-06-caching

📦 या ब्रँचमध्ये काय आहे

धडे 01–04, अधिक memory: program एका वेळी किती धरून ठेवतो, ते tracemalloc ने कसे मोजायचे, आणि Python मधला सर्वात सोपा मोठा उपाय — सगळे items धरून ठेवणाऱ्या list ऐवजी एका वेळी एक item बनवणारा generator. perf/demo.py मधले memory() आणि perf/sim.py मधले total_list, total_gen, peak_kb आणि held_at_once.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

अडथळ्यांच्या शर्यतीला 100,000 अडथळे लागतात (खूपच लांब शर्यत 😄). ते साहित्याच्या खोलीत ठेवलेले असतात. 🏚️

पद्धत 1 — आधी सगळे बाहेर आणा. प्रत्येक अडथळा मैदानावर रचा, मग ते एकेक करून वापरा. मैदान अडथळ्यांनी भरून जाते. दुसऱ्या कशालाच जागा उरत नाही.
पद्धत 2 — एका वेळी एक. ऐश्वर्या एक अडथळा आणते, धावपटू त्यावरून उडी मारतो, ती तो परत नेते आणि पुढचा आणते. मैदानावर कधीही एकच अडथळा असतो.

शर्यत तीच. उत्तर तेच. पण पद्धत 2 ला जवळजवळ जागाच लागत नाही.

यात एक अडचण आहे. पद्धत 2 मध्ये, एकदा अडथळा खोलीत परत गेला की तो मैदानावरून गेलाच. तुम्हाला सगळे अडथळे पुन्हा पाहायचे असतील, किंवा मोजायचे असतील, किंवा वेगळ्या क्रमाने त्यावरून उड्या मारायच्या असतील, तर तुम्हाला पद्धत 1 लागते.

🗺️ आकृती

flowchart LR
    src["range(100,000)"] --> lst["📦 list: [i*i for i in ...]<br/>holds 100,000 results at once"]
    src --> gen["🔁 generator: (i*i for i in ...)<br/>holds 1 result at a time"]
    lst --> sum1["sum → 333,328,333,350,000"]
    gen --> sum2["sum → 333,328,333,350,000"]
    lst --> peak["tracemalloc peak:<br/>list > 100× generator"]

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/performance/lesson-diagrams.html#l05

❓ काय

Allocation — नवीन object ठेवण्यासाठी memory मागणे. Python मध्ये जवळजवळ प्रत्येक गोष्ट object आहे: प्रत्येक int, प्रत्येक str, प्रत्येक list. 100,000 संख्यांची list म्हणजे 100,000 references धरणारा एक list object, अधिक स्वतः ते 100,000 number objects (−5 ते 256 पर्यंतचे छोटे ints share होतात; बाकी बहुतेक स्वतंत्र objects असतात).
Peak memory — program ने कोणत्याही एका क्षणी धरलेली सर्वात जास्त memory. Job त्याच्या container मध्ये मावतो की memory संपल्यामुळे मारला जातो (OOM killer), हे तीच ठरवते.
tracemalloc — Python ने allocate केलेल्या memory blocks चा माग ठेवणारे standard-library module. get_traced_memory() bytes मध्ये (current, peak) परत देते. ते फक्त Python च्या allocations पाहते: काही C libraries थेट घेतलेली memory मोजली जात नाही. अचूक आकडे Python version आणि platform नुसार बदलतात.
RSS (resident set size) — operating system नुसार संपूर्ण process किती memory वापरतो ते. त्यात interpreter आणि libraries येतात, आणि Python मोकळी केलेली memory system ला नेहमी लगेच परत देत नाही. tracemalloc peak आणि RSS वेगवेगळ्या प्रश्नांची उत्तरे देतात.
List — प्रत्येक element आत्ताच बनवते; तुम्ही त्यावर पुन्हा loop करू शकता, index करू शकता, त्याचा len() घेऊ शकता. Generator — अशी कृती जी पुढचा element फक्त मागितल्यावरच बनवते. ती एका वेळी एकच धरते, आणि ती फक्त एकदाच चाळता येते.
Memory मुळे वेळही का खर्च होतो — प्रत्येक allocation हे काम आहे, मोठा heap म्हणजे garbage collector ला पाहायला जास्त, CPU caches मध्ये न मावणारा data वाचायला हळू असतो, आणि RAM संपलेले machine disk वर swapping सुरू करते.

🤔 का

कारण "test file सह माझ्या laptop वर चालले" आणि "खऱ्या file सह production मध्ये मारले गेले" हे वेगवेगळ्या data आकारांचे एकच program आहे. संपूर्ण 10 GB log list मध्ये वाचणाऱ्या report ला 10 GB आणि त्याहून जास्त लागतात; तोच report ओळ-ओळ वाचताना काही kilobytes लागतात. तुम्ही एका वेळी काय धरता हे माहीत असणे, हाच बऱ्याचदा चालणाऱ्या job आणि crash होणाऱ्या job मधला फरक असतो.

🔧 कसे (या repo मध्ये)

perf/sim.py मधले total_list(n) [i * i for i in range(n)] ची बेरीज करते — एक list; total_gen(n) (i * i for i in range(n)) ची बेरीज करते — एक generator. peak_kb(fn, n) tracemalloc सुरू करते, function चालवते, peak वाचते आणि tracing थांबवते. held_at_once हा count model आहे: list साठी n, generator साठी 1. Demo तुलना हो/नाही म्हणून छापतो, कारण अचूक bytes तुमच्या Python version वर अवलंबून असतात.

🧪 करून पाहा

python3 perf/demo.py memory
python3 - <<'EOF'
import sys; sys.path.insert(0, "perf"); from sim import total_list, total_gen, peak_kb
g = (i * i for i in range(5))
print("a generator runs once:", sum(g), "then", sum(g))
squares = [i * i for i in range(5)]
print("a list can be reused:", sum(squares), "then", sum(squares), "· length", len(squares), "· last", squares[-1])
for n in (10_000, 100_000, 1_000_000):
    lk, gk = peak_kb(total_list, n), peak_kb(total_gen, n)
    print(f"n {n:>9,}: list peak {lk / 1024:6.1f} MB · generator peak {gk:5.1f} KB   (exact bytes vary by Python version)")
EOF

शेवटच्या तीन ओळी खरी tracemalloc मोजमापे आहेत — Mac वर Python 3.9 वर ती list साठी सुमारे 0.3 MB, 3.7 MB आणि 38.4 MB आणि generator साठी सुमारे 0.3 KB होती. तुमचे आकडे थोडे वेगळे असतील; नमुना (list n सोबत वाढते, generator वाढत नाही) बदलणार नाही.

✅ तपासा — तुम्हाला काय दिसायला हवे

memory हे छापते:

── the sum of squares of 0..99,999: a list holds every result, a generator makes one at a time
   same answer: True (333,328,333,350,000)
   results held at once: list 100,000 · generator 1
   tracemalloc peak: the list needs over 100× the generator's memory: True

तुमचा snippet याने सुरू होतो:

a generator runs once: 30 then 0
a list can be reused: 30 then 30 · length 5 · last 16

🏁 तुम्ही आत्ताच काय सिद्ध केले

उत्तर तेच, आणि प्रत्येक वेळी n दहा पट वाढल्यावर list ची peak memory दहा पट वाढली, तर generator ची सपाट राहिली — त्याने कधीही एकच वर्ग धरला. पण generator चा दुसरा sum 0 आला: तो संपून गेला होता. म्हणून नियम "generators चांगले असतात" असा नाही; तो असा आहे: "जे फक्त एकदाच चाळायचे आहे ते धरून ठेवू नका".

⚠️ नेहमीच्या चुका

अज्ञात आकाराच्या file वर f.read() किंवा f.readlines() — त्याऐवजी f वर ओळ-ओळ loop करा
"सुरक्षिततेसाठी" generator भोवती list(...), ज्यामुळे संपूर्ण खर्च परत येतो
generator दोनदा चाळणे आणि दुसऱ्या वेळी काहीच न मिळणे
चुकून मोठे objects जिवंत ठेवणे — मर्यादा नसलेला cache (धडा 06), global list, reference ठेवणारा closure
RSS एकदा वाचून तो leak आहे असे समजणे; स्थिर load खाली, वेळेनुसार त्यावर लक्ष ठेवा

🏭 प्रत्यक्ष वापरात

खऱ्या machine वर — दोन snapshots वापरून कोणत्या ओळी सर्वात जास्त allocate करतात ते शोधा:

import tracemalloc
tracemalloc.start()
before = tracemalloc.take_snapshot()
build_results()
after = tracemalloc.take_snapshot()
for stat in after.compare_to(before, "lineno")[:5]:
    print(stat)          # file:line, size and count difference

मोठ्या files आणि query results load करण्याऐवजी stream करा:

with open("laps.csv") as f:              # one line at a time
    best = min(int(line.split(",")[2]) for line in f)

for row in cursor:                       # a DB cursor also streams (fetchmany under the hood)
    handle(row)

memray (Linux आणि macOS) प्रत्येक allocation नोंदवतो, native सुद्धा, आणि flame graph काढतो:

python3 -m pip install memray
python3 -m memray run -o results.bin make_results.py
python3 -m memray flamegraph results.bin

एकाच class च्या अनेक छोट्या objects साठी, __slots__ प्रत्येक instance चा __dict__ काढून टाकतो आणि memory वाचवतो:

class Lap:
    __slots__ = ("runner_id", "lap_ms")
    def __init__(self, runner_id, lap_ms): self.runner_id, self.lap_ms = runner_id, lap_ms

🏭 Production मध्ये हे का महत्त्वाचे आहे: प्रत्येक container वर memory limit ठेवा आणि input च्या आकाराशेजारी memory chart करा. Data सोबत memory वाढत असेल, तर stream असायला हवी होती ती list शोधा.

⏭️ पुढे

कधी कधी सर्वात जलद काम म्हणजे जे तुम्ही पुन्हा करत नाही ते. पुढे: लक्षात ठेवणारा scoreboard — caching आणि memoization, आणि hit ratio.

git checkout lesson-06-caching

🎒 Lesson 05 — Memory: all the hurdles at once, or one at a time?

📍 You are here: Lesson 05 of 12 · Previous: lesson-04-complexity · Next: lesson-06-caching

📦 What's in this branch

Lessons 01–04, plus memory: how much a program holds at once, how to measure it with tracemalloc, and the simplest big fix in Python — a generator that makes one item at a time instead of a list that holds them all. memory() in perf/demo.py and total_list, total_gen, peak_kb and held_at_once in perf/sim.py.

🧒 Explain like I'm 5

The hurdles race needs 100,000 hurdles (a very long race 😄). They live in the equipment shed. 🏚️

Way 1 — carry them all out first. Pile every hurdle on the field, then use them one by one. The field is full of hurdles. There is no room for anything else.
Way 2 — one at a time. Aishwarya brings one hurdle, the runner jumps it, she takes it back and brings the next one. The field only ever has one hurdle on it.

The race is the same. The answer is the same. But Way 2 needs almost no space.

There is one catch. With Way 2, once a hurdle has gone back to the shed, it is gone from the field. If you want to look at all the hurdles again, or count them, or jump them in a different order, you need Way 1.

🗺️ Diagram

flowchart LR
    src["range(100,000)"] --> lst["📦 list: [i*i for i in ...]<br/>holds 100,000 results at once"]
    src --> gen["🔁 generator: (i*i for i in ...)<br/>holds 1 result at a time"]
    lst --> sum1["sum → 333,328,333,350,000"]
    gen --> sum2["sum → 333,328,333,350,000"]
    lst --> peak["tracemalloc peak:<br/>list > 100× generator"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/performance/lesson-diagrams.html#l05

❓ What

Allocation — asking for memory to hold a new object. In Python almost everything is an object: each int, each str, each list. A list of 100,000 numbers is one list object holding 100,000 references, plus the 100,000 number objects themselves (small ints from −5 to 256 are shared; most others are separate objects).
Peak memory — the most memory the program held at any one moment. It decides whether a job fits in its container, or gets killed for running out of memory (the OOM killer).
tracemalloc — a standard-library module that traces memory blocks allocated by Python. get_traced_memory() returns (current, peak) in bytes. It only sees Python's allocations: memory taken directly by some C libraries is not counted. Exact numbers vary by Python version and platform.
RSS (resident set size) — how much memory the operating system says the whole process uses. It includes the interpreter and libraries, and Python does not always give freed memory back to the system at once. tracemalloc peak and RSS answer different questions.
List — builds every element now; you can loop over it again, index it, take its len(). Generator — a recipe that makes the next element only when asked. It holds one at a time, and can be walked through once.
Why memory also costs time — every allocation is work, a bigger heap means more for the garbage collector to look at, data that does not fit in CPU caches is slower to read, and a machine out of RAM starts swapping to disk.

🤔 Why

Because "it worked on my laptop with the test file" and "it was killed in production with the real file" are the same program with different data sizes. A report that reads a whole 10 GB log into a list needs 10 GB and more; the same report reading line by line needs a few kilobytes. Knowing what you hold at once is often the difference between a job that runs and a job that crashes.

🔧 How (in this repo)

total_list(n) in perf/sim.py sums [i * i for i in range(n)] — a list; total_gen(n) sums (i * i for i in range(n)) — a generator. peak_kb(fn, n) starts tracemalloc, runs the function, reads the peak and stops tracing. held_at_once is the count model: n for a list, 1 for a generator. The demo prints the comparison as a yes/no, because the exact bytes depend on your Python version.

🧪 Try it

python3 perf/demo.py memory
python3 - <<'EOF'
import sys; sys.path.insert(0, "perf"); from sim import total_list, total_gen, peak_kb
g = (i * i for i in range(5))
print("a generator runs once:", sum(g), "then", sum(g))
squares = [i * i for i in range(5)]
print("a list can be reused:", sum(squares), "then", sum(squares), "· length", len(squares), "· last", squares[-1])
for n in (10_000, 100_000, 1_000_000):
    lk, gk = peak_kb(total_list, n), peak_kb(total_gen, n)
    print(f"n {n:>9,}: list peak {lk / 1024:6.1f} MB · generator peak {gk:5.1f} KB   (exact bytes vary by Python version)")
EOF

The last three lines are real tracemalloc measurements — on Python 3.9 on a Mac they were about 0.3 MB, 3.7 MB and 38.4 MB for the list and about 0.3 KB for the generator. Your numbers will differ a little; the pattern (the list grows with n, the generator does not) will not.

✅ Verify — what you should see

memory prints:

── the sum of squares of 0..99,999: a list holds every result, a generator makes one at a time
   same answer: True (333,328,333,350,000)
   results held at once: list 100,000 · generator 1
   tracemalloc peak: the list needs over 100× the generator's memory: True

Your snippet starts with:

a generator runs once: 30 then 0
a list can be reused: 30 then 30 · length 5 · last 16

🏁 What you just proved

Same answer, and the list's peak memory grew ten times each time n grew ten times, while the generator's stayed flat — it only ever held one square. But the generator's second sum was 0: it was used up. So the rule is not "generators are better"; it is "don't hold what you only need to walk through once".

⚠️ Common mistakes

f.read() or f.readlines() on a file of unknown size — loop over f line by line instead
list(...) around a generator "to be safe", which brings back the whole cost
walking a generator twice and getting nothing the second time
keeping big objects alive by accident — a cache with no limit (lesson 06), a global list, a closure that keeps a reference
reading RSS once and thinking it is a leak; watch it over time, under steady load

🏭 In production

On a real machine — find which lines allocate the most, with two snapshots:

import tracemalloc
tracemalloc.start()
before = tracemalloc.take_snapshot()
build_results()
after = tracemalloc.take_snapshot()
for stat in after.compare_to(before, "lineno")[:5]:
    print(stat)          # file:line, size and count difference

Stream big files and query results instead of loading them:

with open("laps.csv") as f:              # one line at a time
    best = min(int(line.split(",")[2]) for line in f)

for row in cursor:                       # a DB cursor also streams (fetchmany under the hood)
    handle(row)

memray (Linux and macOS) records every allocation, including native ones, and draws a flame graph:

python3 -m pip install memray
python3 -m memray run -o results.bin make_results.py
python3 -m memray flamegraph results.bin

For many small objects of one class, __slots__ removes each instance's __dict__ and saves memory:

class Lap:
    __slots__ = ("runner_id", "lap_ms")
    def __init__(self, runner_id, lap_ms): self.runner_id, self.lap_ms = runner_id, lap_ms

🏭 Why this matters in production: set a memory limit on every container and chart memory next to the size of the input. When memory grows with the data, find the list that should have been a stream.

⏭️ Next

Sometimes the fastest work is work you don't do again. Next: the scoreboard that remembers — caching and memoization, and the hit ratio.

git checkout lesson-06-caching

← Previouscomplexity Next →caching

This page is the lesson's README from the lesson-05-memory branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.