IntelliJ IDEA 2026.1 Help

Introduction to profiling

Profiling is a type of runtime analysis that operates on large amounts of runtime data and gives you a birds-eye view of what is happening inside a process. The collected data relates to various aspects of program operation, such as CPU usage, memory %allocation, and threads' activity.

Profiling can be instantaneous, like capturing a memory snapshot, or long-running. For example, the CPU profiler can collect data during arbitrarily large periods of time, like hours or even days of program operation.

When is profiling helpful?

Profiling tools help you:

  • Identify bugs, bottlenecks and diagnose poor performance

  • Identify hot spots and opportunities for optimization, not necessarily related to a performance problem

  • Assess or compare the performance of different solutions

  • Get a better understanding of how a program operates under the hood

Supported profiling types

IntelliJ Profiler is not a single tool but rather a suite of related tools. They all have their own area of application:

  • CPU and memory live charts – allow you to monitor a process in real time. This type of diagnostics gives you the resource consumption metrics over time and may be useful as a monitoring tool or, in the case of a performance problem, a starting point for further investigation.

  • CPU and allocation profiling – allow you to see how CPU and memory resources were utilized during a particular period of time. This may be useful for detecting hot code, opportunities for optimization, or just discovering how a program operates at runtime.

  • Memory snapshots – allow you to analyze how memory is used at a particular instant. This data is useful for investigating memory-related issues.

  • Thread dumps - allow you to see the program state at a particular instant. The produced data captures the state of all threads. This may be useful, for example, to examine an unresponsive application.

Available profilers

GoLand uses the built-in profilers from the runtime/pprof package. Each profiler collects a specific type of performance data.

  • The CPU profiler shows where the program spends time while it uses the CPU.

    It helps you find functions that actively perform work, not those that wait for I/O or synchronization.

  • The Heap profiler reports memory usage.

    It shows allocated memory and memory that is still in use. An allocation is a request to reserve memory, for example when you create a slice or a struct. Use this profiler to detect high memory usage and memory leaks.

  • The Allocs profiler reports all memory allocations over time.

    It helps you find code that creates many objects, even if they are short-lived.

  • The Goroutine profiler shows stack traces of all current goroutines.

    A goroutine is a lightweight thread managed by the Go runtime. Use this profiler to understand concurrency and detect stuck or unexpected goroutines.

  • The Block profiler shows where goroutines wait.

    A blocking operation pauses execution until a condition is met. For example, a goroutine can wait for a channel, a lock, or I/O. This profiler helps you find delays caused by synchronization.

  • The Mutex profiler shows lock contention.

    A mutex is a lock that protects shared data. Contention happens when multiple goroutines try to acquire the same lock at the same time. This profiler helps you find delays caused by locking.

  • The Threadcreate profiler shows where the program creates OS threads.

    Use this profiler to detect excessive thread creation and understand how the runtime schedules work.

Configure Go profilers

You can configure Go profilers in the IDE settings. The settings define where profiles are stored and how often the profiler collects data.

Configure profiling for applications

  1. Open settings by pressing Ctrl+Alt+S and navigate to Build, Execution, Deployment | Profilers | Go Profiler: Applications.

  2. Configure global profiling parameters:

    • Default profile directory defines where the IDE stores captured profiles.

    • Memory profile rate defines how often the profiler samples memory allocations.

      The value specifies the average number of bytes between recorded allocations. A lower value increases detail and overhead. The default value is 512 KB.

    • Block profile rate defines how often the profiler records blocking events.

      The value is measured in nanoseconds. Set a lower value to record more events.

    • Mutex profile fraction defines how many mutex contention events the profiler records.

      The value controls the sampling ratio. For example, value 10 means that the profiler records one out of ten events.

Configure profiling for tests

  1. Open settings by pressing Ctrl+Alt+S and navigate to Build, Execution, Deployment | Profilers | Go Profiler: Tests.

  2. Configure profilers for test runs:

    • CPU profiler records CPU usage during test execution.

    • Memory profiler records memory allocations.

      Use Profile rate to define how often the profiler samples allocations. Set the value to 1 to record all allocations. Leave the field empty to use the default value (512 KB).

    • Blocking profiler records blocking events.

      A blocking event happens when a goroutine waits for a resource such as a channel, a lock, or I/O.

      Use Profile rate to define how often the profiler samples blocking events. Set the value to 1 to record all events.

    • Mutex profiler records mutex contention.

      Mutex contention happens when multiple goroutines try to acquire the same lock.

      Use Profile fraction to define what portion of events the profiler records. For example, value 10 means that the profiler records one out of ten events.

How profiling works

GoLand uses the standard Go pprof tool to collect profiling data.

When you start profiling, the IDE builds your application with a temporary overlay. The overlay injects profiling hooks into the build without modifying your source files.

The IDE runs a command similar to the following:

GOROOT=/path/to/go GOPATH=/path/to/gopath go build -overlay /tmp/goland_overlay.json -o /tmp/binary /tmp/binary

The overlay file defines temporary changes that enable profiling. GoLand removes these changes after the run completes.

23 April 2026