DEV Community: Ptagl

Profiling Rust applications with `tracing`

Ptagl — Sun, 15 Mar 2026 00:00:00 +0000

Introduction

When I think about profiling, I do not think about optimization first. I think about visibility and understanding.

Profiling is obviously useful when performance matters, but that is only half of the story. In practice, it is also one of the best ways to understand how a system actually behaves: a function may be called more often than expected, an initialization path may run twice, or a step you assumed was negligible may end up dominating the whole execution.

In this post I will use profiling and tracing in Rust to generate a JSON trace that I can open in Perfetto UI. Perfetto can visualize external traces in Chrome JSON format, which makes it a very convenient way to inspect the output produced by tracing_chrome.

A quick introduction to the `tracing` and `profiling` crates

tracing is widely used in Rust for logging and diagnostics, but its scope is broader than traditional logging. It provides structured events and spans, which makes it useful not only for recording what happened, but also for tracking execution flow, preserving context, and collecting timing information for profiling.

profiling, on the other hand, is a thin abstraction layer that lets you instrument code in a generic way, without tying your application directly to a specific profiling backend. In this post I use it together with tracing, but it can work with other profilers as well.

Creating custom spans

The most direct way to instrument a specific part of your code is to create a custom span around it.

fn main() {
    // Some code
    ...

    {
        profiling::scope!("Main Application Scope");

        // Code to be tracked
        ...
    }

    // Some other code
    ...
}

It is simple, but also surprisingly effective.

Instrumenting functions

Of course, real world applications are more complex than this dummy main function, and it would be inconvenient to call this macro in tens or hundreds of places around the codebase. Luckily, there is a macro that can be used to instrument whole functions very quickly:

#[profiling::function]
fn very_important_function() {
    ...
}

Marking functions with this attribute will make the profiler keep track of every call to it.

Instrumenting implementations

Even this approach could become annoying if it needs to be replicated for several functions to be instrumented.

There is another attribute that comes in handy to simplify our job:


struct VeryImportantStruct {}

#[profiling::all_functions]
impl VeryImportantStruct {
    fn function1() {
        ...
    }

    fn function2() {
        ...
    }

    fn function3() {
        ...
    }
}

This tells profiling to instrument every function found in the implementation body at once, making it way more concise.

Initializing the profiling and exporting the trace

Most of the job is already done, but we need one more step before being able to collect data from our application.

We need to initialize the profiling, specifying the format we need (JSON file compatible with Chrome tracing in this case) and decide when to start and stop collecting data.

It is typically done early in the main function or in some other initialization function, but it can also be started later or even on-demand if needed:

fn main() {
    let _guard = {
        use tracing_chrome::ChromeLayerBuilder;
        use tracing_subscriber::{layer::SubscriberExt, util::SubscriberInitExt};

        let (chrome_layer, guard) = ChromeLayerBuilder::new().build();
        tracing_subscriber::registry().with(chrome_layer).init();
        guard
    };

    // The rest of the application logic
    ...
}

tracing_chrome provides a layer for tracing-subscriber that writes traces in Chrome trace format. Profiling starts immediately after the init() call, and the trace file is finalized when the guard returned by the builder is dropped, so it is important to keep it alive for the whole duration of the profiling session.

If it's dropped earlier for any reason (e.g. the guard is placed in a dedicated initialization function without being returned), the profiling stops. The result of such an error is typically the creation of empty JSON traces!

Analyzing the trace

The full example of instrumented Rust application can be found on my GitHub profile. Once everything is set up, run the application and wait for it to stop. At that point, you should see a new JSON file generated in the current working directory with a name like trace-1773521455925975.json.

There are several ways to open this trace, for instance with the viewer built into Chrome (chrome://tracing) or with Perfetto UI.

Personally, I prefer Perfetto because it provides a modern, clean, and fast UI.

Once you open the trace in Perfetto UI, you get a timeline view of the recorded spans, which gives you an immediate overview of what happened over the lifetime of the application.

By selecting spans or time ranges, you can inspect durations, nesting, timestamps, and the relationships between different parts of the execution.

That is the kind of detail that is easy to miss in logs and easy to spot in a trace.

How to develop a simple Chrome extension

Ptagl — Thu, 26 Feb 2026 00:00:00 +0000

Among all the online services I use, Intervals.icu is one of my favorites when it comes to cycling.
It's a free service where I track my training, analyze power and HR zones, and plan the workouts for the week.
Since AI assistants became actually useful, I started feeding them my workout data to get a second opinion on training load, recovery, and race readiness.

Unfortunately, there was no one-click way to export an activity. My workflow was quite slow and inefficient:
open the activity, copy the summary at the top, switch tab, copy the power zone breakdown, switch again, grab the HR zones, then paste everything into a chat window and hope the AI would make sense of the mess.

What I really wanted was a single button that would collect all that data as structured JSON and put it in my clipboard.

That button didn't exist, and given that the project is not open source, all I could do was to build it, or, to better say, "inject" it into the web page through a Chrome extension.

The skeleton

The web is full of starter templates for Chrome extensions.
You don't need to write the boilerplate yourself: grab any "hello world" extension from GitHub or the official docs, and you'll have a working folder structure in minutes.

The only file that actually matters for this use case is content.js, the script that runs inside the target page.

Three steps to inject anything into websites

The whole logic fits in three steps, and they apply to basically any site you want to extend:

1. Make sure you're on the right page.
The manifest.json already restricts your script to run only on matching URLs (via the matches field in content_scripts).
But sometimes you need a finer check inside the script itself, for example, Intervals.icu activity URLs follow a pattern like /activity/XXXXXXXX, so a quick window.location.pathname check does the job.

2. Find a DOM anchor.
You need somewhere to attach your new element. Open DevTools, inspect the page, and find a stable container near where you want the button to appear. Try to find an element that is easy to select and won't change often.

3. Add your logic.
In my case: call the Intervals.icu API to fetch the full activity JSON, then copy it to the clipboard.

Here are the most important parts of the implementation:

1) Identify the current activity and fetch its JSON

async function getActivityData() {
  // Activity id is the last segment of the current path
  // e.g. /activity/12345 -> "12345"
  const activityId = window.location.pathname.split("/").pop();

  // Intervals.icu endpoint for a single activity
  const apiUrl = `https://intervals.icu/api/activity/${activityId}`;

  const response = await fetch(apiUrl /* (credentials/cookies are handled by the browser session) */);
  if (!response.ok) throw new Error(`API request failed: ${response.status}`);

  return response.json();
}

2) Find a DOM anchor where we can place our button

function getButtonContainer() {
  // Pick a stable container in the activity header area.
  // This is the "anchor" where we attach our UI.
  //
  // NOTE: selectors are site-specific and may break if the UI changes.
  const header = document.querySelector(".gutter8");
  if (!header) return null;

  // Walk down the DOM to the right section (site-specific).
  const rightSection = header.lastElementChild;
  const lastSection = rightSection?.lastElementChild;

  return lastSection ?? null;
}

3) Inject the button and wire up the click logic

function addExportButton() {
  // Avoid duplicating the button if we re-run this function.
  if (document.getElementById(EXPORT_BUTTON_ID)) return;

  const container = getButtonContainer();
  if (!container) return;

  // Minimal wrapper to fit the existing layout (site-specific styling).
  const buttonGroup = document.createElement("div");
  buttonGroup.style = "float: right; padding-right: 12px;";

  // Reuse the site's button classes to blend in.
  const exportButton = document.createElement("a");
  exportButton.id = EXPORT_BUTTON_ID;
  exportButton.className = "btn btn-default";
  exportButton.href = "#";
  exportButton.textContent = "JSON to clipboard";

  exportButton.addEventListener("click", async (event) => {
    event.preventDefault();

    // Fetch JSON and copy to clipboard
    const activityJSON = await getActivityData();
    await navigator.clipboard.writeText(JSON.stringify(activityJSON));

    // Tiny UX feedback: swap label for 2 seconds
    const originalText = exportButton.textContent;
    exportButton.textContent = "Copied!";
    setTimeout(() => (exportButton.textContent = originalText), 2000);
  });

  buttonGroup.appendChild(exportButton);
  container.appendChild(buttonGroup);
}

4) Wait for the DOM to be ready and inject the button

// Use a mutation observer to detect when the page is ready for the injection
const observer = new MutationObserver(() => {
  if (getButtonContainer()) addExportButton();
});

observer.observe(document.body, { childList: true, subtree: true });

// Run once as well (in case the DOM is already ready).
addExportButton();

The full source is available on GitHub.

Testing without publishing

You don't need a developer account to try it out. Just:

Collect all the extension files (in particular manifest.json and content.js) into a folder accessible to the browser
Open chrome://extensions or the extension page of your chromium-based browser
Enable Developer mode

Click Load unpacked and point it at your folder. It's done, the extension is live in your browser.

Publishing on the Chrome Web Store

When you're ready to share it, the process is straightforward but has a few steps:

Create a developer account at the Chrome Developer Dashboard
Pay the one-time $5 registration fee
Upload your ZIP, fill in the store listing (description, screenshots, icons, and other information)

Submit for review

The review can take anywhere from a few hours to a few days. Google's official publish guide walks you through every field.
It's tedious but not complicated.

The whole thing took me a couple of evenings. The extension is tiny, a single content.js and a manifest file, but it sped up my workflow hugely.
If you use Intervals.icu and an AI assistant, give it a try.
And if you want to inject something into a different site, the pattern is exactly the same.

How to use the cache with GitHub Actions - The right way

Ptagl — Tue, 27 Jan 2026 00:00:00 +0000

Introduction

I’ve been using GitHub Actions heavily for CI on my Rust projects lately. I’m always obsessed with increasing execution speed and efficiency, and recently, I thought I had found a clever optimization that turned out to be a huge mistake.

Here is the context:

Development strategy: I keep a main branch on which I merge changes through feature branches and pull requests.
CI workflow: I usually run a standard lint (cargo clippy and cargo fmt), build, and test pipeline. My CI was configured to run on every push to a pull Request. Since I strictly merge PRs via rebase onto main, the CI run on the PR and the hypothetical run on main after the merge are mathematically identical.

So, to save on GitHub Action minutes, I had a "brilliant" idea: I disabled the CI triggers on the main branch.

I thought I was being efficient. In reality, I broke my caching strategy completely.

The Mortal Sin: Ignoring Scope

The moment I disabled the build on main, my cache hit rate immediately dropped to zero. I noticed that every new PR was compiling from scratch, only hitting the cache on subsequent commits within that PR.

The reason lies in how GitHub Actions scopes its cache:

Main Branch: When CI runs on main, the cache it saves is accessible to main and any child branch (future PRs).
PR Branch: When CI runs on a PR branch, the cache is saved and scoped only to that specific branch.

Once a PR is merged, that branch is deleted. If you don't run CI on main to regenerate/update the "central" cache, that data is lost to the void. New PRs cannot access the cache generated by previous PRs; they can only access the cache from the base branch (main).

By disabling CI on main, I ensured that every new PR started with a cold cache.

How to check if you are doing it wrong

You don't need complex metrics. Just look at your CI logs.

If you are using Swatinem/rust-cache or sccache, look at the setup/restore steps.

✅ Good: The logs explicitly state a cache entry was found and restored.

Run Swatinem/rust-cache@v2
Cache Configuration

... Restoring cache ...
Cache hit for restore-key: v0-rust-build-and-test-Linux-x64-xxxxxxxx-xxxxxxxx

❌ Bad: The logs say "No cache found," and it begins downloading the crates registry or compiling dependencies from zero.

Run Swatinem/rust-cache@v2
Cache Configuration

... Restoring cache ...
No cache found.

The Right Workflow

For my Rust setup, I use Swatinem/rust-cache (which is excellent for standard cargo registry/target caching) and for heavier projects, I add sccache to cache the compilation artifacts.

Here is the corrected workflow. It runs both on PRs and main, preventing the "cold start" problem.

name: Rust CI

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

env:
  CARGO_TERM_COLOR: always
  # [Optional] Enable sccache for rustc (not needed if you don't want to use `sccache`)
  RUSTC_WRAPPER: sccache
  # [Optiona] Tell sccache to use GitHub Actions cache API (not needed if you don't want to use `sccache`)
  SCCACHE_GHA_ENABLED: "true"

jobs:
  test:
    name: Test & Lint
    runs-on: ubuntu-latest
    steps:
      # 1. Checkout
      - name: Git checkout
        uses: actions/checkout@v5

      # 2. Setup the toolchain
      - name: Install Rust toolchain
        uses: dtolnay/rust-toolchain@master
        with:
          components: rustfmt, clippy

      # 3. Setup Cargo cache (registry + target)
      - name: Rust Cache
        uses: Swatinem/rust-cache@v2

      # 4. [Optional] Setup sccache (mainly useful for heavy projects)
      - name: Run sccache-cache
        uses: mozilla-actions/sccache-action@v0.0.9

      # 5. Check formatting
      - name: Cargo fmt
        run: cargo fmt --all -- --check

      # 6. Linting
      - name: Cargo clippy
        run: cargo clippy --all-targets -- -D warnings

      # 7. Build
      - name: Cargo build
        run: cargo build

      # 8. Test
      - name: Cargo test
        run: cargo test

References

https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching#restrictions-for-accessing-a-cache

Fix Android Battery Drain With Battery Historian

Ptagl — Sun, 18 Jan 2026 00:00:00 +0000

Introduction

When Android starts draining battery with the screen off, the first thing I do is check the battery report in Settings to see the percentage used by each application. Sometimes it's useful, but other times it isn't. Last time I checked, usage looked normal, but at the bottom of the list there was a suspicious entry marked as Other with a very high percentage. I wanted to know which application or service was contributing to that bucket, but unfortunately it wasn't possible.

When that happens, the best option is to rely on more powerful tools.

A tool still worth trying is Battery Historian, an inspection tool developed by Google that can analyze and show relevant information from ADB bugreports.

It is no longer maintained, and Google suggests to use some alternatives, but Battery Historian is still quite effective and relatively easy to use.

The project's README provides very easy instructions to run the tool with Docker, but, unfortunately, the Docker image they mention is no longer available.

Luckily, there are unofficial images, I used the one published on Docker Hub by itachi1706.

Android Wakeups

We have a problem and also a tool to study it, that's a good starting point. But what are we looking for?

The crucial concept here is system wakeups.

In an ideal idle state, when the screen is off, Android tries to keep the device sleeping as much as possible, while still allowing a few vital tasks to run in the background.

Wakeups (alarms, jobs, wakelocks) are the mechanism that makes this possible, but if they happen too frequently (especially because of non-essential apps/services) the phone never really stays idle, and battery drain becomes very noticeable.

Requirements

USB debugging mode enabled on the smartphone
ADB
Docker

(1) Enable USB Debugging

The USB debugging mode is in the Developer Options section, which is hidden in the settings and needs to be enabled. To do so, it's typically enough to go to Settings -> System Information and tap a few times on the Build Number.

Once enabled, you'll find a lot of settings under the Developer options, among them you need to enable USB Debugging.

(2) Create a report with ADB

There are a couple of ways of installing ADB, I prefer the manual download in the SDK Platform Tools bundle.

Once ready, check if it works properly by running the following command:

adb devices

The output should look like this (if the smartphone is not yet connected to the PC):

* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached

Now, connect the smartphone to the PC via USB. Android should show a request to allow the usage of USB debugging on the detected PC. Accept, then run again the devices ADB command, the output list should now include the smartphone ID:

List of devices attached
XXXXXXXXXXXXXXX device

The next step is to create the Android report:

adb bugreport bugreport.zip

After a while, the report is ready for the analysis.

Note
The report contains data for a window of several hours. It may include noise that makes the following inspection harder. In case, it's possible to reset the statistics to have a better control over the monitoring window:

adb shell dumpsys batterystats --reset

(3) Analyze the report with Battery Historian

Run the Battery Historian container with Docker:

docker run -p 9999:9999 itachi1706/battery-historian:latest

Then open the browser and go to http://localhost:9999/, select the report archive created with ADB and press the Submit button.

The UI includes a timeline chart showing events and metrics about system services and components. Below there is a table with all the details, and the most interesting view is often App Wakeup Alarms. It shows all the services that triggered a system wakeup. Some services are required and it's normal to find them in the rankings (like ANDROID_SYSTEM, GOOGLE_SERVICES, SYSTEM_UI, etc.), but there may be something unexpected.

In my case, the top drainer was the Samsung Health app, got it!

A solution could be completely uninstalling the application, but I needed it, so I better find the root cause. The good news is that it's possible to break down the standings by "alarm name" through the checkbox immediately above the table, providing way more details.

Do you see? It is the background service responsible for the daily step counter. I'm very lucky this time: I don't need my smartphone taking care of this activity because I already have a smartwatch for that purpose, so I can just disable that service from the application settings. To be even more sure, I completely removed any app permission related to "Physical Activity".

After this countermeasure, I didn't experience any battery drain anymore!

Dev Containers: Rust Quick Start

Ptagl — Fri, 16 Jan 2026 00:00:00 +0000

Introduction

Dev Containers let you use Docker to run an isolated development environment, so that your tooling and runtime stack can live “somewhere else” instead of on your host machine.

A devcontainer.json file in your repo defines how to create or connect to that development container (and which tools/extensions/settings to include).

Dev Containers have become pretty mainstream lately, and I’m finding them especially useful in several scenarios, for instance when I need to temporarily set up a development environment or a specific toolchain for a quick test I'll later discard, and I don't want to pollute my host machine.

Requirements

To follow this tutorial, you need to have:

Docker
Visual Studio Code with the "Dev Containers" extension installed

I tested this on Ubuntu 24.04 on WSL2 (Windows 11), but it should work on any platform supported by Docker and VS Code, with minor adjustments.

Adding the Dev Container configuration

First of all, let's create our project folder:

mkdir hello-dev-container && cd hello-dev-container

Then, let's create a file called .devcontainer/devcontainer.json in the project root with the following content:

{
  "name": "Rust Hello World (Dev Container)",
  "image": "mcr.microsoft.com/devcontainers/rust:latest",
  "customizations": {
    "vscode": {
      "extensions": ["rust-lang.rust-analyzer"]
    }
  }
}

If you haven't done it yet, open the project root folder with VS Code:

code .

Then use the Command Palette (Ctrl + Shift + P), and select Dev Containers: Reopen in Container. This command may take a while the first time as Docker needs to download the base image and set up the container. Once finished, the blue bottom-left corner of VS Code should indicate that you are connected to the Dev Container. As an additional confirmation, you can open a terminal in VS Code and see that the environment looks different from your host machine (e.g., the current user is vscode).

At this point, you can continue working as usual; the fact that you are inside a Dev Container is mostly transparent.

Hello World Rust Template

To test the Dev Container with Rust, we need at least a minimal project that can be compiled, run, and eventually debugged. To do so, let's open a VS Code terminal and type:

cargo init --bin --name hello-dev-container
cargo run

You should see the "Hello, world!" string printed to the terminal. The same could be done directly from VS Code by clicking on the buttons on top of the main() function. Debugging works as well.

Testing the environment isolation

To verify that the Dev Container is indeed isolated from your host machine, let's suppose that we want to test our "Hello World" Rust application with the latest nightly toolchain. We could install it on our host machine, but maybe we won't need it beyond this quick test, and we are too lazy to uninstall it later. Instead, we can simply install it inside the Dev Container.

To force cargo to use a specific toolchain version, let's create a file called rust-toolchain.toml in the project root with the following content:

[toolchain]
channel = "nightly-2026-01-15"

VS Code should automatically detect the change and attempt to refresh the project, but the Rust Analyzer extension may fail as the specified toolchain is not yet installed inside the Dev Container.
If you open the extension log, you should see an error like this:

toolchain 'nightly-2026-01-15-x86_64-unknown-linux-gnu' is not installed
help: run `rustup toolchain install` to install it

Let's accept the suggestion and run the command in the VS Code terminal inside the Dev Container:

rustup toolchain install

Once finished, you may need to restart Rust Analyzer, and then the IDE is fully functional again. You can notice, for instance, that we can run or debug the application by clicking on the buttons on top of the main() function.

Since I prefer to verify rather than trust, let's make a quick check. From the IDE terminal, run rustup show. It lists the toolchains installed on the Dev Container, and should include nightly-2026-01-15. Now, if you have Rustup installed on the host machine, you can do the same and compare the output: that toolchain version should not appear unless you installed it on your own, regardless of this tutorial.

Claiming WSL Disk Space

Ptagl — Sun, 11 Jan 2026 00:00:00 +0000

TLDR

Shut down your WSL distributions and use PowerShell (as administrator) to run Optimize-VHD on the VHDX file used by your WSL distribution:

wsl --shutdown
Optimize-VHD -Path '<Path to your VHDX file>' -Mode Full

Introduction

Working with WSL I sometimes see my disk usage grow significantly until the day I'm almost out of space and need to reclaim it somehow. In my case, the reason is that WSL uses a virtual hard disk (VHDX) file to store the file system of each distribution, and over time these files grow in size as data is added, but they don't shrink when data is removed.

Note: this is true unless your WSL distribution is configured to use the "sparse mode", which should automatically resize the VHDX file as needed. However, many people reported issues with this mode (for instance here, here, and here), so it's not considered a reliable solution as of today.

It’s easy to check whether you have this issue too. Since I always forget the path of my WSL VHDX file, I typically use PowerShell to find it:

(Get-ChildItem -Path $env:USERPROFILE\AppData\Local\Packages\ -Filter "*.vhdx" -Recurse -ErrorAction SilentlyContinue).FullName

Copy the path and store it in a variable for convenience:

$VHDXPath = '<Path to your VHDX file>'

Then, check the size of the VHDX file:

"{0:N2} GB" -f ((Get-Item $VHDXPath).Length / 1GB)

Now, it's time to compare this size with the actual used space inside the WSL distribution. To do this, start your WSL distribution and run:

df -h /

If the size of the VHDX file is significantly larger than the used space reported by df, then it's definitely time to reclaim some bytes!

Optimize-VHD to the rescue

Luckily, there is a PowerShell cmdlet called Optimize-VHD that can be used to compact VHDX files. This command reclaims unused space in the VHDX file, effectively reducing its size on disk.

Note: Optimize-VHD is part of the Hyper-V module. Availability on your system depends on your Windows edition and features installed. If you don't have it, you might need to enable the Hyper-V feature on your Windows system via "Turn Windows features on or off" in the Control Panel.

First of all, make sure the VHDX file is not mounted (the easiest way is to stop WSL), then run the Optimize-VHD command as administrator on the VHDX file you found earlier:

wsl --shutdown
Optimize-VHD -Path $VHDXPath -Mode Full

The process may take some time depending on the size of the VHDX file and the amount of unused space to reclaim.

After the command completes, you can check the size of the VHDX file again with the same commands used above to see how much space you've reclaimed.

And that's all, see you next time your disk is full!

DEV Community: Ptagl

Profiling Rust applications with `tracing`

Introduction

A quick introduction to the tracing and profiling crates

Creating custom spans

Instrumenting functions

Instrumenting implementations

Initializing the profiling and exporting the trace

Analyzing the trace

How to develop a simple Chrome extension

The skeleton

Three steps to inject anything into websites

Testing without publishing

Publishing on the Chrome Web Store

Submit for review

How to use the cache with GitHub Actions - The right way

Introduction

The Mortal Sin: Ignoring Scope

How to check if you are doing it wrong

The Right Workflow

References

Fix Android Battery Drain With Battery Historian

Introduction

Android Wakeups

Requirements

(1) Enable USB Debugging

(2) Create a report with ADB

(3) Analyze the report with Battery Historian

Dev Containers: Rust Quick Start

Introduction

Requirements

Adding the Dev Container configuration

Hello World Rust Template

Testing the environment isolation

Claiming WSL Disk Space

TLDR

Introduction

Optimize-VHD to the rescue

A quick introduction to the `tracing` and `profiling` crates