Debugging and Profiling
MIT 6.NULL The Missing Semester of Your CS Education, lecture 7, explained in plain English
Want this lecture to stick? In LessonBound you get checked practice questions for every part, can ask about anything you don't get, and can listen with your screen off. Free, no ads.
Learn this lecture freeWatch or read the original lecture: MIT OpenCourseWare.
Part 1
This part explains several ways to find bugs in code, from printing and logging to debuggers and static analysis, and it does not cover profiling.
Key ideas
- The simplest way to find a bug is to add print statements near the problem and keep adding more until you understand what is going wrong. Logging is a better version of this because it can write to files and filter messages by importance.
- Logging uses severity levels such as INFO, DEBUG, WARN, and ERROR. You can show only the messages that matter for the problem you are chasing.
- Programs that run alongside yours, such as web servers and databases, write their own logs, often under /var/log. When client-side errors are not enough, reading these logs can show you what went wrong.
- A debugger lets you pause a program, move through it one step at a time, and look at variable values, including after a crash. Use it when print statements are not enough.
- Static analysis tools read your source code and check it against coding rules, so they can find some bugs without running the program at all.
Words to know
- severity levels
- Labels such as INFO, WARN, and ERROR that show how serious a log message is, so you can filter out the less important ones.
- debugger
- A tool that lets you pause a running program, step through it slowly, and check what its variables hold.
- breakpoint
- A marked line in your code where the program automatically pauses so you can look around.
- static analysis
- Checking code for problems by reading it with rules, without running it.
Example
Think of a video that you can pause and advance one frame at a time. A debugger works the same way for a program: you can stop it at a chosen moment, go forward one step, and look at what everything is set to. Printing values is more like taking a few still photos along the way.
3 checked practice questions for this part are in the app.
Part 2
This part shows how to find bugs and slow spots in code, using tools that check code without running it and tools that measure how long each part takes.
Key ideas
- Static analysis tools read your source code and check it against rules, so they can catch mistakes like wrong names or type mix-ups before you run the program.
- Linters show these warnings inside your editor, and formatters rearrange your code so it looks consistent. Both help you spot problems and make code easier for others to read.
- Working code can still be too slow or use too much CPU or memory, so it helps to find which parts of the program take the most time before you try to speed anything up.
- Wall clock time includes waiting for things like the network, so the User and Sys times are a better guide to how much work your program actually did on the CPU.
- A line profiler shows the time spent on each line of code, which is easier to understand than the per-function totals from cProfile, especially when third-party libraries are involved.
Words to know
- static analysis
- Checking code for mistakes by reading it, without actually running the program.
- linter
- A tool that checks code for bugs, style problems, or unsafe habits and reports them, often right inside your editor.
- profiler
- A tool that runs your program and measures where it spends its time or resources, so you know which parts to speed up.
- sampling profiler
- A profiler that checks what the program is doing at regular short intervals, instead of recording every single function call.
Example
Think of proofreading a letter before you mail it: you can catch a misspelled name just by reading it, without sending it first. Timing a recipe works the same way: you check how long each step takes, so you know which step is eating most of your evening.
3 checked practice questions for this part are in the app.
Part 3
This part teaches how to find out where a program spends its time and memory, using tools that measure each line, show system events, and display results in easy-to-read pictures.
Key ideas
- A line profiler measures how long each line of a function takes to run, so you can find the slow line instead of guessing. In the example, one line took about 96.5% of the function's time.
- A memory profiler shows how much memory each line adds or frees. In Python, memory is not freed while something still points to it, so checking memory use is still useful even though Python cleans up for you.
- The perf tool does not report time or memory. It reports system events about your program, such as poor cache locality or page faults, which can explain why a program is slow.
- Profiler output for real programs is large, so tools turn it into pictures. A flame graph shows function calls stacked from top to bottom, with the width of each block showing how much time it took.
- Before profiling, it helps to check resource use with tools like htop, df, and ss. Programs often run slowly when they lack memory or have a slow network connection.
Words to know
- garbage collected
- When a language cleans up memory that the program no longer needs, so the programmer does not have to free it by hand.
- memory leak
- A bug where a program keeps memory it no longer needs, so the memory is never released.
- flame graph
- A picture that shows which functions a program calls and how much time each one takes, with the wider blocks taking more time.
- black box
- Something you use without looking inside. You judge it only by what goes in and what comes out.
Example
Think of a road trip that took six hours. Instead of guessing, you write down how long each stop took, and you find that the lunch stop took four hours. A line profiler does the same thing for a program, showing which line took most of the time.
3 checked practice questions for this part are in the app.
← Lecture 6: Version Control (Git) · Lecture 8: Metaprogramming →
Notes written by AI (Claude) from the lecture's official transcript, so check anything important against the lecture. MIT CSAIL · CC BY-NC-SA 4.0 · not affiliated with or endorsed by MIT. These notes are shared under the same license.
LessonBound · Free lecture notes · Privacy · Terms · New York