Sponsored by
Hello friends!
Welcome to this week’s Sloth Bytes. I hope you had a great week.
Typing is a thing of the past
Typeless turns your raw, unfiltered voice into beautifully polished writing - in real time.
It works like magic, feels like cheating, and allows your thoughts to flow more freely than ever before.
With Typeless, you become more creative. More inspired. And more in-tune with your own ideas.
Your voice is your strength. Typeless turns it into a superpower.
Profilers For Dummies
Every developer will encounter this situation one day:
You write some code, it works and you’re proud!
But… It’s super slow.
Now you stare at the code and suffer in silence because you have no idea what’s wrong.
This is where where profilers come in.
What’s a Profiler?
A profiler measures where a program spends time or allocates resources so you can find performance hotspots. Different profilers answer different questions: CPU time, elapsed/wall time, allocations, heap growth, call frequency, I/O waits, and more.
Think of it like a fitness tracker for your code.
Fitness trackers don’t just say you did exercise, It shows what type of exercise:
You spent 20% of your run walking,
10% climbing stairs,
30% sitting on the couch,
and 40% scrolling TikTok.
For code, this means you can see:
Which functions are called most often
Where CPU time is being spent
Which code allocates or retains lots of memory
Where elapsed time disappears into network, database, filesystem, locks, or sleep/waiting
A profiler gives you evidence about where resources are going. It does not automatically tell you the root cause—you still have to interpret the measurement and understand the workload.
Types of Profilers (and when you’d use them)
I’ll be using Python (as usual) since it’s easier to understand the examples.
CPU Profilers
Use case: Your program is slow and you want to know which Python functions dominate execution time or call count. Python’s cProfile is a deterministic profiler: it observes function call/return events and records timing statistics.
# cpu_example.py
def cpu_heavy():
total = 0
for i in range(5_000_000):
total += i * i
return total
def called_often():
return sum(i for i in range(100))
cpu_heavy()
for _ in range(100_000):
called_often()Run it with Python’s built-in deterministic profiler:
python -m cProfile cpu_example.pycProfile reports elapsed timing around function calls, so a function waiting on sleep() or I/O can still appear expensive. If you specifically need to distinguish CPU time from wall-clock waiting, use tools/metrics designed for that question—for example Python’s time.process_time() excludes time spent sleeping, while time.perf_counter() measures elapsed time.
Output example
Memory Profilers
Memory profilers help answer questions such as: which lines allocate memory, what objects are still reachable, and whether the live heap keeps growing across repeated work.
Use case: Memory usage grows over time, the process gets killed for exceeding its limit, or you suspect objects are being retained longer than intended.
# memory_example.py
import tracemalloc
tracemalloc.start()
before = tracemalloc.take_snapshot()
# Run the workload you want to investigate.
data = [[i] * 100 for i in range(50_000)]
after = tracemalloc.take_snapshot()
for stat in after.compare_to(before, "lineno")[:10]:
print(stat)Python’s standard library includes tracemalloc, which can take allocation snapshots, compare them, and show the traceback where allocated memory came from.
python memory_example.pyOutput example
Sampling Profilers
Sampling profilers periodically inspect what the program is doing instead of instrumenting every function event. Because they observe samples rather than every call, they can have lower overhead and work well for profiling longer-running or production-like workloads.
Use case: You want a statistically useful picture of hotspots with less instrumentation overhead. Rare/very short functions may be missed if they do not appear in enough samples.
Output example
Real-World Profilers
Python:
cProfile,tracemalloc, py-spy, line_profilerJavaScript: Chrome DevTools Performance/Memory panels, Node.js/V8 profiling tools
Java: Java Flight Recorder / JDK Mission Control, VisualVM, commercial profilers
Go: pprof
C/C++: platform tools such as perf, Instruments, VTune, heap/memory checkers, and compiler instrumentation
If your language has a runtime, it probably has a profiler.
What Developers Usually Look For
When developers run a profiler, they’re not scanning every number.
They’re hunting for patterns:
CPU hotspots: Which call stacks consume most CPU time?
Wall-time / I/O bottlenecks: Is latency coming from databases, networks, files, locks, or other waits rather than CPU?
Allocation hotspots: Which code creates large amounts of short-lived memory?
Memory retention/leaks: Which objects remain reachable and cause the live heap to grow?
Garbage-collection pressure: Is excessive allocation causing frequent or long GC work?
Call frequency: Is a cheap function slow overall because it runs millions of times?
Algorithmic scaling: Does performance grow badly as input increases, suggesting an algorithm/data-structure problem?
When to Use a Profiler
When your code runs too slow and you can’t tell why
When you suspect a memory leak
Before optimizing (so you don’t waste effort)
After big changes, to catch regressions early
During performance reviews or stress tests
A Simple Profiler Workflow
If you’ve never used a profile that’s fine!
Here’s a simple workflow just in case you feel like trying one:
Define the symptom and metric
Latency? CPU saturation? memory growth? throughput? Pick the thing users/systems actually care about.Reproduce a representative workload
A profile of toy input can point at a completely different hotspot than production-shaped data.Choose the right profiler
CPU, wall-time, allocation/heap, sampling, tracing—use the tool that measures the suspected resource.Find the largest meaningful hotspot
Do not optimize a function that is 50% faster but represents 0.01% of total runtime.Change one thing
Algorithm, query, allocation pattern, cache, batch size, I/O strategy, etc.Measure again under the same conditions
Profilers have overhead, benchmarks have noise, and intuition lies. Compare before/after instead of declaring victory because the code looks cleverer.
Optimizing performance is not always simple and the problems aren’t always obvious, but a profiler gives you the map.
It shows you where a slowdown is and it’s often in places you’d never expect.
So if you’re ever in a situation where your code feels slow, try a profiler!
If you want me to dive deeper into specific profilers let me know!
If you want to keep learning
Debugging techniques — when the bug is about correctness rather than performance.
Big O notation explained — understand how an algorithm should scale before measuring how it behaves in the real world.
Error handling explained — design failures so they’re easier to understand, recover from, and debug.
Memory leaks explained — one of the most common problems memory profilers help uncover.
Thanks to everyone who submitted!
grcc492, JunKaiPhang, AryanTheIndoDev, jmartinl, Wakorithegreat, NeoScripter, AspenTheRoyal, alfalconetti, SanjnaSukirti, and jsjasee.
Looks like graph like problems are difficult for you all 😏
So let’s do another one!
Can You Exit the Maze?
You are given a 2D matrix representing a maze, where 0 is a walkable path and 1 is a wall.
You start at the top-left corner and you have to reach the bottom-right corner.
Write a function that returns true if a path exists.
You can only move up, down, left and right. You cannot move diagonally.
Examples
canExit([
[0, 1, 1, 1, 1, 1, 1],
[0, 0, 1, 1, 0, 1, 1],
[1, 0, 0, 0, 0, 1, 1],
[1, 1, 1, 1, 0, 0, 1],
[1, 1, 1, 1, 1, 0, 0]
])
output = True
canExit([
[0, 1, 1, 1, 1, 1, 1],
[0, 0, 1, 0, 0, 1, 1],
[1, 0, 0, 0, 0, 1, 1],
[1, 1, 0, 1, 0, 0, 1],
[1, 1, 0, 0, 1, 1, 1]
])
output = False
# This maze only has dead ends!
canExit([
[0, 1, 1, 1, 1, 0, 0],
[0, 0, 0, 0, 1, 0, 0],
[1, 1, 1, 0, 0, 0, 0],
[1, 1, 1, 1, 1, 1, 0],
[1, 1, 1, 1, 1, 1, 1]
])
output = False
# Exit only one block away, but unreachable!
canExit([
[0, 1, 1, 1, 1, 0, 0],
[0, 0, 0, 0, 1, 0, 0],
[1, 1, 1, 0, 0, 0, 0],
[1, 0, 0, 0, 1, 1, 0],
[1, 1, 1, 1, 1, 1, 0]
])
output = TrueThat’s all from me!
Have a great week, be safe, make good choices, and have fun coding.
If I made a mistake or you have any questions, feel free to comment below or reply to the email!
See you all next week.
What'd you think of today's email?
Want to advertise in Sloth Bytes?
If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.
