GuideAdvanced
Python Performance and Profiling
Intuition about what makes a program slow is almost always wrong, and optimizing without measuring is the most common way to waste time fixing the part that was never the problem. This guide teaches the complete optimization process under the one rule that matters: measure first, change second. You work through a single realistic case — Nómada, a command-line tool that processes trip logs for a vehicle fleet and takes four minutes to generate a monthly report — and take it down to a few seconds using the real method: timing with the correct clock, profiling with `cProfile` to find where the time actually goes (almost never where the team thinks), measuring memory cost, choosing the right data structure for the problem, and applying the specific optimization that fits each real bottleneck. The guide also teaches you to recognize when pure Python no longer cuts it and work needs to be pushed to vectorized code, and how to document and protect an optimization so it doesn't get lost in the next refactor. The final project requires an honest report of what changed, how much each change gained, and what was deliberately NOT optimized and why.
- 64
- lessons
- 8
- modules
- English · Spanish
- available in
- Yes
- certificate
- Free
- access
Outcomes
What you'll be able to do
- Time code with the correct clock and avoid the micro-benchmark trap that measures something different from what matters in production
- Use Python's profiler (`cProfile`) to find a program's real bottleneck, distinguishing own time from cumulative time
- Measure a program's memory usage and recognize when a data structure doesn't fit and generators or batch processing are needed
- Choose between a list, a set, and a dictionary based on the real access pattern, understanding the hidden cost of operations like `in`
- Apply concrete optimizations to an already-identified bottleneck: moving work out of a hot loop, memoization, lazy evaluation, reducing function calls
- Recognize when an algorithm change beats a thousand syntax-level micro-optimizations
- Identify when pure Python no longer cuts it and work needs to move to numeric arrays and vectorized operations
- Document why a piece of optimized code looks "weird," and write performance tests that warn when an improvement regresses
- Verify that an optimization still gives the correct result, not just that it's faster
- Report honestly what was optimized, how much was gained, what it cost in readability, and what was deliberately left untouched
Before you start
What you need to bring
It's for you if...
- Intermediate-level Python developers with a slow script or service they never systematically measured to find out why
- Devs who already tried "optimizing" by changing code blindly and found the time didn't drop
- Teams where every person has a different theory of where the bottleneck is and nobody verified it with a profiler
- People preparing technical interviews where they're asked about algorithmic complexity, memory usage, or how to diagnose slow code
- Anyone who needs to decide, with judgment rather than by fashion, when optimizing is worth it and when the maintenance cost outweighs the gain
Requirements and materials
- Know Python: functions, classes, data structures, comprehensions, and having written programs beyond a simple exercise
- No prior experience with profiling or performance-measurement tools is required
- It helps to have felt the real problem: a script that takes too long without knowing why, or a change that "should have" sped something up and didn't change anything
- No need to know concurrency (async, threads, processes) or databases: those topics live in their own guides
Content
The syllabus, module by module
Open any of them to see its lessons.
- 1. Module introduction: your program's heat map
- 2. Your first profile with Python's profiler
- 3. Reading a profile without drowning
- 4. Own time and cumulative time
- 5. The function called a million times
- 6. Profiling line by line
- 7. Profiling without distorting what you measure
- 8. Project: find the real bottleneck
- 1. Module introduction: what you don't see being consumed
- 2. Why memory matters for speed
- 3. Measuring how much memory your program uses
- 4. The list that didn't fit: generators
- 5. Objects, dicts and what they weigh
- 6. Memory leaks in a garbage-collected language
- 7. Processing without loading everything at once
- 8. Project: make Nómada fit in memory
- 1. Module introduction: the decision that speeds things up the most
- 2. List, set, dictionary: when each one
- 3. Searching fast: the hidden cost of `in`
- 4. Complexity, in plain language
- 5. When changing the structure changes everything
- 6. Standard-library structures almost nobody uses
- 7. The cost of building vs the cost of querying
- 8. Project: rewrite the data join
- 1. Module introduction: now yes, with the profile in hand
- 2. Moving work out of the hot loop
- 3. Compute once and remember: cache and memoization
- 4. Lazy work: not computing what isn't used
- 5. The house functions are in C
- 6. Fewer calls: the cost of calling a function
- 7. When a better algorithm beats a thousand tweaks
- 8. Project: optimize the real bottleneck
- 1. Module introduction: the ceiling of the language
- 2. Why Python is slow (and when it doesn't matter)
- 3. Pushing the work into compiled code
- 4. Numeric arrays: when your data is numbers
- 5. Vectorizing instead of iterating
- 6. The right tool for data work
- 7. Recognizing when it's no longer worth it in Python
- 8. Project: speed up the numeric computation
- 1. Module introduction: optimizing is easy, maintaining it isn't
- 2. Readable or fast: the real tradeoff
- 3. Documenting why this code is weird
- 4. Performance tests that warn if it degrades
- 5. The optimization that stopped helping
- 6. Measuring in production, not just on your machine
- 7. The cost of maintaining optimized code
- 8. Project: protect the optimization
- 1. Module introduction: the complete process, from start to finish
- 2. Measuring the honest baseline
- 3. Finding the three bottlenecks
- 4. Attacking the biggest first
- 5. Knowing when to stop
- 6. Verifying it's still correct
- 7. Reporting what you gained and what it cost
- 8. Final project: optimize Nómada end to end
Common questions
What people usually ask
No limit. It's a free guide: come in whenever you like, as often as you like.
No. Modules run from easier to harder, but you can jump to the one you need. Progress is saved per lesson.
Whatever is needed is listed under “What you need to bring”, above. If nothing is listed there, you can start from zero.
In the Club's WhatsApp group, and every two weeks there's a live with an instructor where questions get worked through.
Yes. It's issued automatically once you finish every lesson, with a verifiable code you can share on LinkedIn.
Start whenever you like
What students say
These reviews are from enrolled students who completed at least 50% of the course. We moderate reviews only on content grounds (spam, offensive language, personal data), never for being critical or negative.
No approved reviews yet.
Be the first to share your experience!