Scrolls
4 min read
On this page

Print vs Debugger vs Profiler

Most engineers have a default debugging tool. Some litter code with print statements. Some step through every problem in a debugger. Some reach for profilers when things feel slow. The engineers who debug fastest are the ones who know when to reach for each tool. Print debugging, interactive debuggers, and profilers solve different categories of problems, and using the wrong one wastes time.

The Three Tools

Print debugging:  Insert output statements to trace execution flow and values
Debugger:         Pause execution, inspect state, step through code interactively
Profiler:         Measure where time and resources are being spent

Each is best suited for a specific category of problem. Choosing the right one first — rather than starting with your default and switching when it does not work — is the core skill.

Print debugging is underrated by experienced engineers and overused by beginners. Both reactions are wrong. Print debugging is the right tool when you need to understand flow and values across time, especially in systems where pausing execution changes behavior.

When Print Debugging Wins

- Tracing execution flow across multiple functions or services
- Debugging concurrent or async code (debuggers change timing)
- Production debugging where you cannot attach a debugger
- Distributed systems where the bug spans multiple processes
- Quick hypothesis testing ("does this branch even execute?")
- Bugs that disappear under a debugger (Heisenbugs)

How to Print Debug Well

Bad print debugging is print("here") and print("here2"). Good print debugging is structured and intentional.

Bad:
  print("here")
  print("here2")
  print(x)
  print("made it")

Good:
  print(f"[payment] process_payment called: amount={amount}, token={token[:8]}...")
  print(f"[payment] gateway response: status={resp.status}, body={resp.body[:200]}")
  print(f"[payment] charge saved to db: id={charge.id}, state={charge.state}")

Rules for effective print debugging:

1. Label every print with the module or function name
2. Include the variable NAME, not just its value
3. Truncate large values (first 200 chars, not the whole object)
4. Use a consistent format so you can grep the output
5. Print at decision points: before/after conditionals, loop boundaries
6. Include timestamps if timing matters
7. Remove all debug prints before committing (or use a logging level)

Structured Logging Over Print

In production code, do not use print. Use structured logging:

# Instead of: print(f"User {user_id} failed to login")
logger.warning("login_failed", user_id=user_id, reason=reason, ip=request.ip)

# This gives you:
# - Log levels (filter noise)
# - Structured fields (query and aggregate)
# - Consistent format (parse with tools)
# - Automatic context (timestamp, hostname, request ID)

The advantage of structured logging over print is that you can leave it in the codebase. Good logging is documentation. Good prints are trash you need to clean up.

Interactive Debuggers

Debuggers let you pause execution, inspect the full program state, evaluate expressions, and step through code line by line. They are the right tool when you need to understand complex state at a specific moment in time.

When Debuggers Win

- Complex state inspection (nested objects, large data structures)
- Understanding unfamiliar code paths (step through to learn)
- Conditional breakpoints ("stop only when user_id == 42")
- Inspecting the call stack and variable scope at failure point
- Modifying values mid-execution to test hypotheses
- Bugs where you know WHERE it fails but not WHY

When Debuggers Fail

- Concurrent or multi-threaded code (pausing one thread changes timing)
- Distributed systems (cannot pause all services simultaneously)
- Production environments (usually cannot attach a debugger)
- Performance-sensitive code (debugger overhead changes behavior)
- Bugs that depend on real-time behavior (network timeouts, animations)

Debugger Techniques Beyond Breakpoints

Most engineers only use basic breakpoints. Debuggers can do much more:

Conditional breakpoints:
  Break only when a condition is true.
  "Stop here only when amount > 10000"
  Saves you from hitting the breakpoint 999 times before
  the interesting case.

Watch expressions:
  Monitor a variable's value as you step through code.
  The debugger shows you the current value at every step
  without you typing it.

Step over vs step into vs step out:
  Step over:  execute the current line, skip function internals
  Step into:  enter the function being called
  Step out:   finish the current function, return to caller
  
  Most debugging is step over. Only step into when you
  suspect the called function is where the bug lives.

Evaluate expressions:
  Run arbitrary code in the current scope while paused.
  "What would happen if I called user.is_admin() here?"
  Test hypotheses without changing code.

Reverse debugging (where available):
  Step backward through execution. Available in rr (Linux),
  some IDE debuggers, and time-travel debugging tools.
  Extremely powerful for "how did we get into this state?"

Debugger Setup Matters

The reason many engineers avoid debuggers is that setup is painful. Invest 30 minutes once to configure your debugger properly:

Setup checklist:
  1. Configure source maps (for compiled/transpiled languages)
  2. Set up launch configurations for common scenarios
     (run tests in debugger, attach to running process)
  3. Learn the keyboard shortcuts (F5, F10, F11 in most IDEs)
  4. Configure remote debugging if you work with containers
  5. Learn how to attach to an already-running process

The 30-minute setup investment pays for itself the first time you use it.

Profilers

Profilers measure where your program spends time, allocates memory, or uses other resources. They are the right tool when something is slow and you do not know why. They are the wrong tool for everything else.

When Profilers Win

- "The page takes 8 seconds to load" (where is the time going?)
- "Memory usage keeps growing" (what is leaking?)
- "CPU spikes every 5 minutes" (what is running?)
- Optimizing hot paths in performance-critical code
- Comparing before/after performance of a change

Types of Profilers

CPU profilers:
  Show which functions consume the most CPU time.
  Two modes:
    Sampling: takes snapshots at intervals (low overhead, statistical)
    Instrumented: measures every function call (high overhead, exact)
  Use sampling for production, instrumented for development.

Memory profilers:
  Show what is allocated, how much, and by whom.
  Critical for finding memory leaks.
  Look for objects that grow over time but are never freed.

I/O profilers:
  Show time spent waiting for disk, network, or database.
  Often more useful than CPU profilers for web applications,
  which are typically I/O-bound, not CPU-bound.

Flame graphs:
  Visual representation of where time is spent.
  Width = time consumed. Depth = call stack.
  The widest bars are your hotspots.

Profiling Workflow

1. Establish a baseline: measure current performance with numbers
2. Profile under realistic conditions (production-like data, load)
3. Identify the top bottleneck (singular, not plural)
4. Optimize that one bottleneck
5. Measure again to confirm improvement
6. Repeat from step 3

Do NOT optimize based on intuition. Profile first.
"I think this function is slow" is not evidence.
"This function takes 340ms out of a 400ms request" is evidence.

Common Profiling Tools

Language    CPU Profiler         Memory Profiler
Python     cProfile, py-spy     tracemalloc, memray
Node.js    --prof, clinic.js    --inspect heap snapshots
Java       async-profiler       JFR, VisualVM
Go         pprof                pprof (heap profile)
Rust       perf, flamegraph     DHAT, heaptrack
Ruby       stackprof            memory_profiler

Browser:   Chrome DevTools Performance tab
           (covers CPU, memory, rendering, network)

Decision Framework: Which Tool When

Problem                          Tool
-----------------------------------------
"What value does X have here?"   Print or Debugger
"Does this code path execute?"   Print
"What is the state when it       Debugger
 crashes?"
"Why is this slow?"              Profiler
"Which of these 3 services       Print (with correlation IDs)
 is causing the error?"
"The bug disappears when I       Print (debugger changes timing)
 try to inspect it"
"I don't understand this code"   Debugger (step through it)
"Memory keeps growing"           Memory Profiler
"Works in tests, fails in        Print + logging (can't usually
 production"                      attach debugger to prod)

Combining Tools

The best debugging sessions often use multiple tools in sequence:

Typical flow for a performance bug:
  1. Profiler: identify the slow function
  2. Print: add logging around the slow path to understand inputs
  3. Debugger: set a breakpoint in the slow function, inspect state
  4. Profiler: verify your fix improved performance

Typical flow for a logic bug:
  1. Print: trace execution to find where behavior diverges from expectation
  2. Debugger: pause at the divergence point, inspect full state
  3. Print: add logging to confirm the fix works across many inputs

Real-World Example: The Slow Dashboard

A team reported that a dashboard page took 12 seconds to load. An engineer's first instinct was to add print statements in the API handler. The prints showed the API responded in 200ms. So the problem was not the API.

Next, they opened Chrome DevTools profiler. The Performance tab showed 11 seconds spent in a single JavaScript function: renderChart(). Drilling in, the function was creating 50,000 DOM elements for a chart that displayed 50,000 data points.

The fix was to aggregate the data server-side and send 500 points instead of 50,000. The dashboard loaded in 400ms.

Without the profiler, they would have spent days optimizing the API that was not the bottleneck. The profiler pointed to the exact function in seconds.

Common Pitfalls

  • Only using one tool — print-only engineers miss the power of state inspection. Debugger-only engineers struggle with concurrent systems. Profiler-averse engineers optimize by intuition. Learn all three.
  • Reaching for the profiler when the bug is logical — profilers tell you about performance, not correctness. If the function returns the wrong result, a profiler will not help.
  • Leaving print statements in production code — either use proper structured logging that can stay, or clean up your prints. Stale debug output is noise that makes future debugging harder.
  • Profiling with unrealistic data — profiling with 100 rows when production has 10 million rows will not find the real bottleneck. Profile under production-like conditions.
  • Over-relying on debuggers for concurrent code — pausing one thread changes the timing of all threads. Race conditions often disappear under a debugger. Use print-style logging with timestamps instead.

Key Takeaways

  • Print debugging is best for tracing flow, debugging concurrent systems, and production issues. Do it well: label outputs, include variable names, use structured logging in production.
  • Debuggers are best for inspecting complex state at a specific point. Learn conditional breakpoints and expression evaluation, not just basic stepping.
  • Profilers are for performance problems only. Always profile before optimizing — intuition about what is slow is usually wrong.
  • Match the tool to the problem type. Flow questions need prints. State questions need debuggers. Speed questions need profilers.
  • The best debugging sessions use multiple tools in sequence, switching as you narrow the problem.