Code profiling 101, and the 3 Types of Code Profilers


3 Types of Profilers: Matt Watson, Founder & CEO / Stackify

For those of you do do not know a lot about Stackify, we do a lot of things around application performance and have actually written a couple profilers ourselves.

Today I want to talk about the three different types of profilers and describe the differences between them and talk about some tools you should have in your toolbox as a developer.

What is code profiling?

I did a search on the internet and I found this definition:

“A person or device that creates a profile, especially someone with psychological training to assist police investigations with identifying the likely characteristics of the perpetrator of a particular crime.”

I thought that was kind of a weird definition, but with a few changes that would work perfectly:



All right, well, it sort of works. In short, profilers are used by developers to help them find performance problems.

So, what exactly does code profiling do?

Typically they’re used by developers, without changing their code, to help identify performance problems. It can answer questions like how many times each method in your code is called and how long does each of those methods take. It tracks things like memory allocations and garbage collection. Some profilers also track key methods in your code so you can understand how often SQL statements are called and web service calls. Some profilers can track web requests and the train those transactions to understand the performance of transactions within your code. Profilers can track all the way down to each individual line of code or the CPU instructions, which is very slow. Most profilers that developers use are for when they’re having a very bad day. Usually they’re chasing a CPU problem or memory problem and in doing so, go out of their way to try and find those problems. It usually makes your application run a hundred times slower than it normally would. While it’s not something you do every day, profiling can be a total lifesaver when you have a bad CPU problem or something you’re trying to track down.

So, let’s explore other reasons why you need a profiler. It’s all about improving the performance of your code. They’re great for finding the hot path in your code, such as figuring out what uses twenty percent of the total CPU usage of your code and determining how to improve that. They help you look for methods that can lead to improvement a little bit at a time. A great thing that a former mentor told me is, “If you can improve something one percent every day, it doesn’t seem like a big improvement, but over the course of a month, you’re thirty percent better.” Sometimes, depending on your type of application, where performance really matters is just the ability to do continual little tweaks that add up over time.

Profilers are great for finding memory leaks early. And of course, they’re great for understanding the performance of dependency calls (such as a SQL database call accessing something like Redis for caching, for example) and transactions.

When you think about profilers you can have two different levels: high level and low level. A high level profiler tracks performance of maybe just key methods in your code. These profilers typically will do transaction timing, such as tracking how long a web request takes, while also giving you visibility to errors and logs.

Low level code profiling can be very slow and has a lot of overhead, potentially making your app a hundred times slower than it should be. When you’re using this kind of profiler, it usually tracks performance of every single method in your code and potentially, every single line of code within each method. These types of profilers are also tracking memory allocations and garbage collection to help with memory leaks. They’re very good at finding that hot path, figuring out every single method that’s being called, and what’s using the most CPU.

The other way to think about these is that the high level performance profiling is probably what you would use on a server so that you can track the performance of your application when you have thousands of users logged into your app. It’s very high level, it’s very low overhead, and these are typically the APM kind of products that exist.

Then you have the desktop type profilers which is going to be Visual Studio or other profilers. These too are very low level. So you can have a server-based versus your desktop-based. There’s also a kind of hybrid.

A hybrid allows you to get some of the same detail from server-based profiling, but also to get back to your desktop so you can use it every day. So, we’ll get a high level overview with low overhead just like you do on your servers but we’re going be able to track the performance of key methods, track every single transaction that happens, track the dependency calls, and errors logs.

Tools that align to these three different types of profilers

For application performance products (APM) that run on servers—at Stackify we have a product called Retrace—you have other big companies in the space like New Relic and App Insights from Microsoft and there’s several other products in this space.

At the desktop level you have code profilers like the Visual Studio Profiler and NProfiler, which is a cool product that I’ve used. Redgate has ANTS; JetBrains has a product called dotTrace and there’s several other products. So these are the profilers you would use on your desktop. All these are based on .NET, but the same terminology and the same sort of concepts work for other programming languages as well.

There are three hybrid tools for .NET. You’ve got a Stackify product called Prefix, which is free. There’s an open source product called Glimpse; this is a pretty cool tool.

Now on these server-based and hybrid products, some of them use the actual profiler built into .NET or the programming language, and some of them collect data outside of being a profiler. Some of them require a lot of code changes; it depends on the product. So, that’s something to think about. Some of these products you install on your server and you just go; you don’t have to do any changes to your code. Some of these products may require code changes or a lot of config changes. Keep that in mind as well as you use these tools.

So there’s three types of profilers:

  1. You have that low-level standard kind of profiler, which most of you have  probably used. Again, it was probably a bad day when you were using it. You were probably chasing a weird CPU problem. You probably don’t use that low-level profiler very often,  maybe a couple times a year.
  2. The other type that we’ve talked about is that kind of hybrid lightweight profiler that you can use while you’re doing development. They’re awesome to use every single day and they don’t slow you down. They can help you find performance and application problems.
  3. And then you have profilers for your servers which is that APM type product that you can run on your servers that has a low overhead and you can track performance all the time.

Again, Prefix is a free tool that we provide and I definitely recommend checking it out. It’s one of those things that once you use it you can’t imagine not having it. It’s definitely a missing link for developers to let them know what their app is doing.


– – – – – – – –

If you liked the content of this webinar, check out more from our series on dev tools in the lasted edition of BuildBetter, our free eMag.