The search page has been getting slower for weeks, and a senior engineer has finally run a profiler on it. They drop an image into the team channel with one line. Looks like most of the time is in the serialisation layer. The image is a wall of coloured bars stacked on top of each other, some wide, some thin, with names too small to read. Everyone reacts with a thumbs up. You nod along and have no idea what you are looking at.
This is worth learning, and it is less difficult than it looks. A flame graph is just a picture of where a program spends its time, and once you know how to read one you will find performance problems far faster than by guessing.
Start with what the shape means. The profiler pauses the program many times a second and records which functions were running at that moment. The flame graph adds those samples together. Each bar is a function. The width of a bar is how much of the time that function, and everything it called, was on the stack. Wider means more time. The bars stacked on top of it are the functions it called.
Then learn the one thing people most often get wrong. In the most common layout, left to right is not time. The bars are usually sorted alphabetically, not in the order things happened. So do not read it like a timeline. Read it like a map of where the cost is.
Look for the wide plateaus near the top. A wide bar with nothing much above it is a function doing a lot of work itself, rather than handing it on. That is usually where the interesting question is. Is this function slow, or is it simply being called far more often than anyone intended?
Make one yourself. Most languages have a profiler that can produce a flame graph, and many have one built into the standard tools. Pick a small program you understand, perhaps one with a loop you know is slow, and profile it. Seeing your own code in the picture, where you already know the answer, teaches you more than any article.
Then compare two. Profile something, make one change, and profile it again. Seeing a bar shrink after your fix is the clearest proof you will get that the fix did what you thought.
Know the limits. A flame graph shows where the processor was busy. If the page is slow because it is waiting on a database or another service, the waiting may not show up at all in some profilers, and you may need a different kind of tool. It is worth asking which kind the senior engineer used.
And next time the image appears in the channel, ask them to walk you through it for five minutes. Most people who can read these love explaining them.
– Asael Shinder
Top comments (0)