Pinterest replaces its profiler patchwork with Intel’s open-source gProfiler

When you have five services written in one language, profiling takes a single command. When you have hundreds of thousands of instances and five languages, profiling becomes an engineering challenge in its own right. That is the problem Pinterest faced, and its solution is an interesting one: instead of building a proprietary internal system, the company adopted Intel’s open-source gProfiler and began extending it.

The problem: many languages, many tools

The scale looks like this: 640 million monthly active users and hundreds of thousands of compute instances. Services are written in Java, Python, C++, Go and Node.js. Engineers had a familiar tool for each language: perf for native code, async-profiler for the JVM and py-spy for Python.

Each is good on its own. Together, they create a mess. Data formats differ, launch procedures differ, and piecing together a view across a chain such as “Node.js gateway, Java backend, C++ library” requires manual work. Comparing a service’s profile across machines or across days is also difficult when the snapshots come from different tools.

For the infrastructure team, this is no academic concern. Profiles help explain where hardware spending goes and catch regressions after a release. Fragmented data makes those questions slower to answer, with less confidence.

What changed in gProfiler

gProfiler is an open-source continuous profiler. It runs as an agent on a machine, collects profiles across multiple languages and presents the results as flame graphs. Pinterest worked with Intel to extend its capabilities and contributed the changes back to the open-source project. The improvements include:

• Dynamic profiling. Profiling can be enabled and configured while systems are running, rather than kept on continuously across every machine.
• Hardware-level telemetry collection. The profiler captures not just where code spends time, but also data from processor counters.
• Wall-time profiling. Shows where a thread spends time waiting, rather than only where it uses the processor.
• Flame graphs based on performance counters. Graphs can be built around hardware events instead of the usual “CPU time” axis.

An example makes the difference between CPU time and wall time easier to understand. Suppose an endpoint responds in 300 ms, but the CPU profile shows just 40 ms of processor activity. Where did the other 260 ms go? Most likely, the thread was waiting for a database response, the network or a lock. A CPU profile will not show that portion at all, while a wall-time profile will reveal it immediately.

Performance counters let you look deeper. Two functions might take the same amount of time, but one might constantly miss the processor cache. A conventional profile will not distinguish between them; a hardware-event profile will.

What matters here, and what we do not know

The original announcement provides no figures for compute resources saved, how much faster regressions are identified or how many instances have already migrated. It is therefore too early to claim a measurable impact. This is more a statement of architectural direction than a results report.

Still, the choice itself is telling. A company of this size could have built its own platform, but chose an open-source project and contributed its improvements back. That benefits everyone else: improvements to dynamic and wall-time profiling will become available to anyone using gProfiler.

What to do in practice

1. Take stock of your tool sprawl. If you have more than two languages in production and more than two different profilers, you have the same problem, just on a smaller scale.
2. Try gProfiler in a test environment. It is an open-source project designed specifically for continuous profiling without changes to service code.
3. Make wall-time profiling a habit. If a service is “slow, but the CPU is idle,” this is what you need.
4. Watch upstream developments. Pinterest and Intel’s improvements are expected to reach the main repository, and it is worth checking which are already available in releases.

The main takeaway is simple: at scale, a unified profiler matters more than the perfect tool for each language. Comparable data across the entire fleet delivers more value than the best possible precision in a single service.