Lalit Maganti (Notes only)

What I'm Changing After A Year Of Blogging

Fri, 17 Jul 2026 00:00:00 +0000

Writing for the world is something which has ebbed and flowed for me over time. I’ve always liked sharing my thoughts, starting with websites all the way back when I was a kid. In times when I sustained it, I had various “blog”-like things for technical projects which would often veer into sharing personal beliefs as well.

It’s been a year since my latest attempt at what I expect to be a lifelong endeavor. So I’ve been reflecting on how it’s gone, and that’s led me to make some decisions on how I want to rework things going forward.

Raising the importance of articles

I have two goals with my writing:

I want the freedom to write what I want and put as much or as little effort into it as I like.
I care a lot about presenting the work I think is good in the best way possible to readers.

Although it might not seem like it, these goals are somewhat in conflict with each other. Sometimes I’ll write up TILs or low-effort posts which may not be that interesting to most people, and I don’t want these mixed up with my best work in the eyes of readers encountering me for the first time.

I’m by no means unique in this; lots of internet writers have the same dilemma and take different approaches to dealing with it. Two options I considered are:

High-effort content on the blog, low-effort content on social media.
Separating content on the blog into high-effort (articles, essays) and low-effort (notes, snippets, TILs, etc.).

I don’t like option 1 because I don’t particularly like social media. I was off it completely for years and have begrudgingly come back because it’s useful for sharing things with people, but it’s not something I enjoy. More importantly, I want everything I write to live on my own site, under my control, rather than scattered across platforms I don’t own.

Instead I’ve taken option 2: I’ve decided to more strongly separate articles and notes from each other.

Knock-on effects on Substack

The main way I’m doing this: I’m no longer going to be sending out notes over email on Substack. I initially conceived of Substack as a “newsletter” of sorts, rounding up everything new on the blog since the last edition. But over time I’ve come to dislike the effect this has: I don’t feel like sending out a newsletter until a high-effort article is ready to go with it. If nothing is ready, I end up just waiting, sometimes for more than a month. Why? Because I don’t want a newsletter edition which doesn’t put my best self forward.

This might all be a me thing: I don’t know how many of my newsletter readers mind if I send them low-effort things. But I feel bad about it, and I think that’s enough for me to not do it.

So instead I plan on reworking it from a newsletter into an articles-only feed. When an article is ready, I’ll publish it on the blog and send it out over email on the same day. I’m going to try to do this on Saturdays, though I can’t promise I’ll always manage it.

At the bottom of each email, I’ll also leave a short “since I last sent you an article, I published thoughts on X, Y and Z”. But it’ll be a one line footnote, not the full content as I do today.

If folks do want to subscribe to everything, my suggestion (see the subscribe page) is to use RSS or an RSS-to-email service. Setting one up on my side would require either managing emails myself (which I think would be painful), manually copying posts to Substack (the tedium disincentivizes me from writing the short posts), or paying for a second email service alongside Substack (which I don’t want to do unless someone will actually use it). If you want everything from me in your inbox, reach out as it will help me decide if I should change my mind.

Site changes

This also knocks on to the homepage. In my previous redesign post I discussed how I switched to a two-pane dashboard feel and categorized what I wrote into three things: essays, write-ups and notes.

While this was certainly cool and I liked it, I also constantly fell into the trap of having content which could debatably fall into either essays or write-ups. So I’ve erased that distinction: both are now simply articles, reflecting the effort and thought I’ve put into them. Notes remain much the same as before.

I also went back to a single chronological feed, because readers gave me the feedback that they liked seeing at a glance if something was new, rather than scanning across three distinct sections to try to work it out. Articles are still clearly differentiated from notes though: they’re bigger, bolder and have explicit labels.

Unrelatedly, I also spent a bunch of time improving RSS. After dogfooding my own feeds, I realized I had made some real mistakes in the way the feed was generated: content was losing all its links and being shortened. Now full articles are published properly to the feed (though things like sidenotes still won’t look the same as on the website).

Closing thoughts

All in all, I feel a lot happier after figuring out how I wanted to handle high- vs low-effort content and deciding on making the Substack articles-only. My best work now gets presented in the way I want, and that makes me feel a lot freer to publish the imperfect stuff too.

Perfetto v57: fixing PyTorch traces, plus journald logs and an AI skill

Fri, 03 Jul 2026 00:23:00 +0100

We just released Perfetto v57 and I wanted to share the new things I’m most excited about. This is something I wanted to do for past releases but I just never quite got round to it. It’s also something I plan on doing more of going forward: there might even be dedicated pieces if I think the feature deserves it!

PyTorch traces reliably work!

What I’m most excited about in this release isn’t a feature but a bugfix. If you used the PyTorch profiler and opened the resulting trace in Perfetto, there was a decent chance some of your events would just not show up; specifically this would happen when these events overlapped each other on a single track.

Technically, PyTorch is in the wrong here. The Chrome Trace Event (JSON) format says duration events on a track have to nest and can’t overlap; if you need overlap, you’re supposed to use async events. chrome://tracing appears to handle them, but its rendering is actually buggy as soon as a trace has real overlaps; people just learned to live with it. So when a bug came in January about overlapping events being broken, I closed it as working-as-intended because I couldn’t see any easy fix from our end.

Then over time, I realized it wasn’t just one person with a weird trace. The bug had affected many different PyTorch traces, and even JAX traces. I even discovered that people were maintaining forks and hosting old versions of Perfetto just to deal with this issue. This is basically Hyrum’s Law: it doesn’t much matter what the spec says, once enough people rely on some behaviour, that behaviour is your contract.

This is also a very similar situation to what I discussed in Perfetto and open source: it was genuinely hard for me to tell just how many people it was affecting at the beginning: if I had understood, I would have dealt with this very differently.

In any case, in v57, Perfetto now imports the overlapping events instead of dropping them, overflowing the extras onto a different line in the same UI track. I do have to credit @i_komarov who helped me understand how big this issue was and to converge on the fix.

Recording systemd journald logs

Perfetto has always tried to give you as much context as possible about what the system is doing and put it all on a single timeline. One missing piece of that on Linux has been in logs from journald; there’s a ton of useful information there but until now it was hard to correlate that with e.g. scheduling or other app level information.

With v57, there’s now a linux.systemd_journald data source that records journald entries straight into the trace, on the same timeline as everything else. You can filter by minimum syslog priority, by SYSLOG_IDENTIFIER, or by systemd unit, so you are not pulling in the entire journal when you only care about one service.

To show it in action, here’s a trace I recorded on my own machine. Alongside a few log lines I generated myself, it happened to capture a real udisks SMART error that fired while I was recording; exactly the kind of thing you’d otherwise miss.

I have to shout out @staticfloat who contributed this feature; thanks a lot for doing this!

An AI skill for recording and analysis

For a while now, people have been building their own AI tooling around Perfetto. SmartPerfetto and perfetto-mcp are two public examples I’ve come across but many teams inside Google have built their versions of these which each handle a subset of Perfetto’s functionality. To us, this is a sign that there’s demand out there to build something upstream so that everyone can benefit.

v57 includes an installable AI skill that works with Claude Code, Codex, Pi, Opencode, Antigravity, and anything else that speaks the Agent Skills format. It explains to the agent how to record traces (Android only for now!) and then query them. It also includes dedicated workflows for debugging Android memory, a specific area of focus for us; we plan on expanding these workflows over time including to Linux.

The skill is just one piece of a much larger AI plan, which I wrote up as an RFC. We will be doing much more in this space in the coming months.

State tracks

State tracks are a new kind of primitive in Perfetto, sitting alongside slices and counters. They represent something that is always in exactly one state: a connection that is open or closed, a device that is on or off, a worker that is idle or busy. You could already model this with slices, by emitting a slice that starts when a state begins and ends when it changes. This works but you have to be careful to emit events exactly at the same timestamps or you end up having gaps.

With a state track you don’t emit start and end events at all. At each point where the state changes, you emit one event that says what the state is now. The previous state ends automatically. Clearing the track marks it idle. This just makes it a lot simpler to manage.

While the simpler emission model is the obvious win, the reason we made it a first-class primitive goes further than that. Because a state track holds exactly one value at any moment, it can never overlap itself, and the trace processor can lean on that guarantee to treat it specially. You can attach arguments that change as the state does. And in ring-buffer traces, where old events get overwritten as the buffer wraps, you can periodically re-emit the current state, so a trace that starts mid-stream still knows what state everything is in.

State tracks are still quite new so there are likely to be some rough edges here, but we think they’ll become an important primitive: because they’re guaranteed never to overlap, you can do things with them you simply couldn’t before.

Querying traces over HTTPS

I recently discovered that quite a few folks have written scripts which download a trace and then run queries against it with the trace_processor CLI. Which made me think: why don’t we just support that natively inside the CLI itself?

So in v57, trace_processor takes an http(s) URL or a ui.perfetto.dev share link directly. It streams the trace and runs your query with no local copy. Here it is against the journald trace from the previous section:

$ trace_processor query \
 "https://lalitm.com/traces/journald-demo.pftrace" \
 "select log_source, count(*) as n from logs where msg is not null group by log_source"

"log_source","n"
"systemd_journald",30

It’s one of those small polish features which you wouldn’t necessarily think of immediately but when you have it, you’d never want to go back.

Lightning round

A few smaller things also landed:

Shift + mouse wheel scrolls the timeline horizontally. A tiny change that removes a daily papercut when you are panning around a wide trace.
The query results grid got a real overhaul. You can sort, reorder, and hide columns, the sidebar collapses, and SQL errors now show up in the grid instead of disappearing.
Adjacent slices that share a boundary render with a 1px gap, so a run of back-to-back slices reads as separate slices rather than one solid block.
Saved textproto record configs are editable, saving the trouble of downloading the config, deleting it, editing it locally, and then reuploading.

Wrap up

Overall this was a pretty solid release of Perfetto; it’s always satisfying to fix a bug blocking a lot of people. AI skills and state tracks are both first steps in a much longer journey, and journald logs are an important new capability that improves our Linux support. The rest are mostly a bunch of small quality of life improvements which are always nice to see!

On "When impressive performance gains do not matter"

Tue, 30 Jun 2026 16:25:00 +0100

When impressive performance gains do not matter is a very nice article covering some ways in which going after performance alone is not sufficient without considering the wider picture. It resonated a lot with how I think about performance.

If there are multiple bottlenecks in the pipeline—and with these systems, this is common—the overall throughput will not improve until every last bottleneck is removed.

His focus is on distributed systems bottlenecks, but I’ve hit the same “do-nothing” speedups when optimizing client side programs. Usually this comes from spending a lot of time thinking something was the bottleneck when it wasn’t. CPU profiling is where this bites me most: it tells me “function X is taking 30% of the cycles” and I think “oooo, there’s a lot of gains to be made there”. I build a microbenchmark for X, optimize it and there’s only a marginal gain at the high level. While disappointing, I’ve become used to it over time and internalized that performance is highly non-linear and actually knowing where the problem lies is really hard.

One specific pattern I’ve run into several times: if you are processing a lot of data and that requires you to hit main memory, you can do quite a bit of computation at the same time on that data for free. This is because out-of-order processors are very good at doing computation while stalled on RAM. So removing instructions in paths like that won’t actually matter; what matters much more is your data structures and reducing how much memory you’re touching.

While I’m on this topic, I have to shout out Matt Kulukundis’s CppCon talk on Abseil’s flat hash map, as it’s what helped me distill my experiences into actual rules of thumb around building performant systems. I would highly recommend you watch it if you are remotely interested in performance!

As for the post, I also like the closing reflection:

Performance work can be incredibly challenging, but it is also a discipline for intimately understanding complex systems and engineering better products.

That matches my own experience: the lasting value isn’t any single speedup, it’s the improved understanding of the system you’re building and is invaluable for making things better in the long term.

syntaqlite 0.6: SQLite dot commands and pyodide

Wed, 17 Jun 2026 21:53:00 +0100

Since my original launch post for syntaqlite, I’ve been quietly working away on it in the background. A lot of the work has been fixing correctness bugs which I discovered as I integrated it into production as the parser for PerfettoSQL in the Perfetto trace processor: as I wrote previously, this has been my dream for over 8 years so it’s amazing to see it finally realized.

Just today, I released syntaqlite 0.6, the most interesting release since the original launch, so I wanted to talk about what’s new.

The biggest step forward for real world applicability is that we now support SQLite dot commands:

.print 'running foo now';
.read foo.sql;

.print 'running bar now';
.read bar.sql;

select * from baz;
-- ^ baz will error if it's not part of the schema!

SQLite scripts are very common in the wild and in the past we would simply error on dot commands like .read and .print, causing spurious warnings and an inability to format files like this properly. Now, these lines will be silently ignored while still parsing, formatting and validating the SQL inside!

In followup releases, I plan on making syntaqlite more aware of the semantics of these dot commands, especially .read: we should be able to do things like verify the file exists or to use the contents of those files for populating schemas etc.

Along with this, the release of Pyodide 314.0 last week means that we can now publish Python wheels to PyPI for Pyodide: I’ve taken advantage of that to immediately add support for it. So you can now go to the Pyodide playground and run the following:

import micropip
await micropip.install('syntaqlite')

import syntaqlite
sq = syntaqlite.Syntaqlite()

# Formatting
print(sq.format_sql('select 1', keyword_case='upper'))
# SELECT 1;

# Analysis
schema = syntaqlite.Schema(
 ddl="CREATE TABLE users (id INT, name TEXT, email TEXT, active INT)")
print(sq.analyze("SELECT nme FROM users WHERE active = 1", schema,
 output=syntaqlite.AnalysisOutput.TEXT,
 render_options=syntaqlite.RenderOptions(source_name="query.sql")))
# warning: unknown column 'nme'
# --> query.sql:1:8
# |
# 1 | SELECT nme FROM users WHERE active = 1
# | ^~~
# = help: did you mean 'name'?

This is another step on the journey towards a 1.0 release which I can now see appearing on the horizon!

TIL: Iroh: peer-to-peer networking for app developers

Tue, 16 Jun 2026 02:36:00 +0100

I came across Iroh (via, via) today as it hit 1.0 and found it a really interesting solution to a problem I knew existed but had not thought a lot about.

Judging from the comment sections, it seems pretty clear that lots of people are confused as to exactly what Iroh is. I don’t think their launch post does their product justice at all, and their tagline is “IP addresses break, dial keys instead” which sounds cool, but if you think about it for just a second, you’ll end up with lots of questions. The biggest one is: “so how is this different from a mesh VPN like Tailscale, ZeroTier, Netbird, etc.?”

It’s only after reading a lot of developers’ comments on the threads that I feel I understand: Iroh is aimed at application developers who want to communicate P2P between machines running their app, while mesh networks are aimed at network admins who want to connect devices they own/manage together.

Imagine you’re developing a peer-to-peer messaging app where, on one side, the user is on a mobile device which constantly roams between WiFi/mobile data (so doesn’t have a stable IP address), and the other side is a laptop sitting behind a NAT and a CGNAT.

If I want to get these folks to talk to each other, I need some mechanism to deal with two problems at once: the mobile’s address keeps changing as it roams, and neither side has a stable public IP the other can reach directly. Now, historically to fix these problems, the developer would need to have an intermediary server which both endpoints talk to so they can share state, create a protocol to exchange IP addresses, and do NAT hole-punching to set up the connection, falling back to acting as a real relay if none of that is possible [1].

What Iroh does instead is standardise this as a set of libraries and protocols as well as offer it as a managed service that you can just drop into your app. They also appear to be leaning heavily on standards like QUIC instead of reinventing the wheel, which is always nice to see.

Overall, this is a pretty neat idea for a difficult problem! I’m definitely curious to try it out; I don’t have a use case in mind, but I’m now on the lookout for one!

[1] If you want to learn more on this, I would strongly suggest reading this excellent Tailscale article which I learned a lot from myself.

Which country voted the best at Eurovision?

Sun, 17 May 2026 15:30:00 +0100

Eurovision was on yesterday. I’ve never been interested much in the musical side but the weird political dynamics of Eurovision voting have always fascinated me; I tune in each year just for them and somewhat snarky commentary of Graham Norton, the UK commentator.

As I was watching the jury votes come in, a question popped into my head: Which country has voted the best in Eurovision? That is, which country was best at picking the eventual top 10 and in the right order?

Strangely enough, while there’s plenty of work on voting blocs and bilateral biases at Eurovision, most of it asks who votes for whom; I wanted to ask who votes accurately. I couldn’t find anyone asking the question that way, so I decided to do some data analysis myself.

The metric

To begin to answer this question, I first needed to formalize what “best” even means. That is, some mathematical notion of “good” and “bad”.

The simplest measure I could come up with is “of the 10 countries you gave points to, how many were in the actual top 10?”. The problem is that it can’t tell apart a voter who gave the eventual winner 12 from one who gave them 1. That feels wrong: an allocation is a ranking, not just a set, so position ought to matter.

To weight position, I needed some scheme for how much position 1 matters compared to position 10. Turns out Eurovision itself has already answered this question: the 12, 10, 8, 7, 6, 5, 4, 3, 2, 1 it hands out is exactly such a scheme. So I just reused it.

So I tried the next simplest thing: for each country, I have two numbers: what the voter awarded it, and how many points it actually received at the end. Multiply them together, sum across all countries, and divide by the maximum value that sum could possibly take if the voter had ranked everything perfectly (awarded 12 to the actual winner, 10 to second place, and so on). The result is between 0 and 1, where 1 is a perfect vote.

A worked example. The actual jury top 5 in 2023, by points received, was Sweden (340), Israel (177), Italy (176), Finland (150), Estonia (146). Imagine a voter’s jury panel awarded (12 → Italy, 10 → Sweden, 8 → Estonia, 7 → Israel, 6 → Finland).

Here’s the voter’s score:

Voter awarded	Country	× Actual points	=
12	Italy	× 176	2,112
10	Sweden	× 340	3,400
8	Estonia	× 146	1,168
7	Israel	× 177	1,239
6	Finland	× 150	900
		Sum	8,819

And here’s the perfect score for this voter, what they’d have got if they had awarded the 12 to the actual top scorer, the 10 to second, and so on:

Voter awarded	Country	× Actual points	=
12	Sweden	× 340	4,080
10	Israel	× 177	1,770
8	Italy	× 176	1,408
7	Finland	× 150	1,050
6	Estonia	× 146	876
		Sum	9,184

So this voter’s score is 8,819 / 9,184 = 0.96. Close to perfect: the same five countries are there, just slightly out of order.

Is it the right metric?

Obviously this is not the only metric I could have used and there are many other candidates out there: least-squares distance to the perfect vote, NDCG@10 (a standard ranking measure used in search), and Pearson correlation.

I went with the one above because I wanted the simplest thing which still worked. Least-squares is the only “simpler” alternative I can think of, but its scores end up squashed into a narrow range. The best voter across nine contests only reaches around 0.42 out of a theoretical max of 1.0, which is the highest score in the data but doesn’t read like a good number. The metric above sits more naturally on a 0-to-1 scale: the best voters land in the 0.8s, the worst in the 0.6s, and 1.0 still means a perfect vote.

In any case, I did run all the metrics listed above and they mostly agreed, with the same countries clustered at the top and bottom regardless of which one I used. But the headline #1 did shift between the top three or four countries depending on which metric I picked.

The answer

I picked 2016 as the start because that’s when Eurovision split each country’s contribution into separate jury and televote slates, each awarding their own 12, 10, 8, … points. Older contests used a single combined vote, so the data doesn’t decompose the same way.

Across these nine contests, here’s the full table:

Rank	Country	Score
1	Spain	0.815
2	Lithuania	0.810
3	Belgium	0.804
4	Germany	0.798
5	Netherlands	0.797
6	Malta	0.792
7	Sweden	0.790
8	Austria	0.789
9	Iceland	0.788
10	Norway	0.783
11	Israel	0.778
12	Latvia	0.777
13	Finland	0.777
14	Moldova	0.774
15	Poland	0.773
16	Romania	0.771
17	Estonia	0.770
18	San Marino	0.770
19	Ireland	0.762
20	Armenia	0.762
21	Cyprus	0.761
22	Denmark	0.757
23	Albania	0.754
24	Slovenia	0.751
25	Australia	0.749
26	Azerbaijan	0.746
27	Serbia	0.745
28	Portugal	0.743
29	Switzerland	0.739
30	Czechia	0.735
31	Croatia	0.733
32	United Kingdom	0.723
33	France	0.712
34	Georgia	0.707
35	North Macedonia	0.706
36	Greece	0.691
37	Bulgaria	0.688
38	Ukraine	0.675
39	Italy	0.666
40	Montenegro	0.625

Spain edges it, but only barely. The top seven are within 0.025 of each other, narrower than the year-to-year variation of any individual country, so calling Spain “the” best voter is too strong a statement.

A few countries often discussed in bloc-voting analyses do show up near the bottom; parts of the Balkans (Croatia, North Macedonia, Bulgaria, Montenegro) and Greece. But it’s only suggestive: others from the same blocs (Cyprus, Albania, Serbia, Armenia) sit comfortably mid-table, so this metric isn’t really measuring bloc voting; it’s measuring accuracy, which is a different thing. Properly disentangling the two would need more analysis work I don’t really want to do!

A note on data

All voting data is from EurovisionAPI/dataset, a scraped mirror of the EBU’s published results. As a sanity check on the two most recent contests I parsed the Wikipedia voting tables for 2024 and 2025 and diffed every cell against the dataset and got no differences.

All my code is available on GitHub.

Rendering 100k trace events faster with exponential search

Tue, 03 Feb 2026 21:07:04 +0000

We’ve recently been looking into optimizing rendering performance of the Perfetto UI on large traces. We discovered that there was some inefficiency in our data fetching logic, especially when you’re very zoomed out.

In this case, there can be a lot of slices (spans) which are so small that they take less than one pixel of width. So for each pixel, we need to figure out “what is the event which we should draw for this pixel”. Over time we’ve come to the conclusion that the best thing to draw is the slice with the largest duration in that pixel.

We can break this into two sub-problems:

What is the range of events which correspond to each pixel?
What is the event with the maximum duration for that pixel?

We’re going to focus on 1) in this post as that’s where the slowdown was. 2) is fascinating but also surprisingly orthogonal. If you’re interested, I would suggest reading this excellent post from Tristan Hume explaining the basic algorithm we use.

So let’s formalize our setup for 1): we have a sorted array containing N (where N is O(100k)) int64 timestamps. The timestamps come directly from the Perfetto trace file so we cannot make any assumptions on values or the distribution. But generally speaking, traces tend to have a mix of dense clusters of events (i.e. lot of activity) and large gaps between these clusters (i.e. not much going on). So it makes sense to optimize for this sort of data pattern.

We then need to find the indexes corresponding to the “lower bound” of M regularly-spaced timestamps (A, A+S, A+2S… B), where each corresponds to a pixel boundary and S corresponds to the “time in the trace represented by one pixel”.

Data: | | | · · | | | | | | | | | | · · · | | · · · · | | | | | | |
 dense sparse dense

Queries: ↓ ↓ ↓ ↓ ↓
 A A+S A+2S A+3S B
 │ │ │ │ │
 ▼ ▼ ▼ ▼ ▼
Result: lb(A) lb(A+S) lb(A+2S) lb(A+3S) lb(B)

The obvious solution, and what we’ve been doing for the last few years, is to just binary search each of the M values independently giving us O(M × log N). This is very fast when N is reasonable but when we get into O(100k) on high resolution screens (meaning M is also relatively large), you end up taking several milliseconds to do these queries.

My first approach was to use “static search trees” to speed up the searches; ever since I had come across this amazing post last year, I had been itching to find a place to use them. They worked great and definitely made things faster, but it was a lot of code and required hand-written AVX and a deep understanding, which I knew would be difficult to get through review. And I had this nagging feeling there was something much simpler I could do.

Eventually I had a key realization: I wasn’t using the fact that the queries themselves are sorted! By using this, we can do much better and achieve O(M + log(N)) performance instead!

How? Using a cool technique called exponential search!

You start by binary searching for A just like before giving you an index I. But for every timestamp after that, instead of binary searching, you do something which looks like a hybrid between linear search and binary search.

Found A at index i, now searching for A+S:

Index: i i+1 i+2 i+3 i+4 i+5 i+6 i+7 i+8
Data: [A] [ ] [ ] [ ] [ ] [A+S] [ ] [ ] [ ]
 ↑ ↑ ↑ ↑ ↑
 start +1 +2 +4 +8
 <A+S <A+S <A+S >A+S
 overshot!

 └───────────────────────┘
 binary search here

Take A + S: at I+1, I+2, I+4, I+8…, you check if the timestamp at that position is greater than A + S. If not, you continue to the next one. If it is, then you stop and instead binary search between the previous position you checked and the current one.

This is much faster than just binary searching both theoretically and practically. Theoretically, notice how we scan the same memory at most twice; once for the exponential scan, once in the binary search afterwards. This is unlike the “binary search everything” approach where the same piece of memory could be touched M times, if the data layout was pathological. This is where the O(M × log N) -> O(M + log N) improvement comes from.

Note that this also applies to static search trees which also have O(M × log N) complexity; exponential search turned out to beat them too!

Practically, the initial exponential scan is great for CPUs which love scanning through memory linearly instead of jumping around randomly like binary search does. By significantly reducing the binary search range, you significantly reduce the chance of cache misses.

A final micro-optimization you can do is, when the number of indices you are binary searching is fewer than 16 (empirically chosen), you can just replace with a linear scan instead. At those sizes, you find that the branching and looping from binary search is actually slower than brute force checking everything (especially with the auto-vectorizer helping you out!).

We switched to exponential search in this Perfetto PR and in our microbenchmark (on real trace data!), we saw an improvement from 1.5ms to 180us - a speedup of 8x! This, along with a bunch of other improvements we made, should help make the Perfetto UI faster and smoother on large traces!

Homepage Redesign, Light Mode and More

Sat, 06 Dec 2025 23:50:00 +0000

Just a quick note documenting some recent changes to the blog. Nothing groundbreaking, but enough accumulated updates that I wanted to write them down.

Homepage Redesign

The homepage used to be a chronological list of articles; your classic default blog format. I’ve redesigned it into more of a two-pane “dashboard” feel. The reason? My content is quite varied: I have long essays and technical write-ups but also short TIL or notes posts (like this one!). Having a way to differentiate between them while also scanning across the titles of different types of posts felt really valuable.

I was inspired by this post which I stumbled across.

Light Mode Returns

A couple of days ago, a reader emailed me and asked if I could add a light mode to the blog because they were reading in a bright environment. Though personally I prefer dark mode, I appreciate not everyone agrees so it made sense to add.

Here’s the funny part: the blog actually had a light mode in its early days. I removed it because maintaining two color schemes with the site generator setup I had (Hugo, PaperMod Theme, Tailwind, custom CSS rules on top) was a significant maintenance cost.

I only endured all this complexity because I thought offloading the theming to someone else meant I could focus on the writing and not turn this into yet another “programming project”. But, unfortunately, I have very strong feelings about how I want things to look. Trying to work within the theme’s extension points while also being opinionated was far more trouble than doing everything myself.

So I ripped out all of that complexity. Stripped Tailwind, simplified the CSS dramatically, went back to basics. Once I did that, adding light mode became trivial. A few CSS variables and a toggle: done!

I briefly considered writing my own static site generator (inspired by this article) but Hugo does the job well enough (if you stay away from its dark corners) that I abandoned the attempt after a few hours.

Typography Refresh

I also did a bunch of tweaks to the typography:

Fonts: Moved from system fonts to Inter for headings and body content, Source Code Pro for code blocks and monospace usage. Ensures everyone gets the same experience and makes readability consistent; on some machines, I felt legibility suffered if the system font was poor.
Size: Bumped up font sizes throughout. The previous sizing felt a bit hard to read, the new one should be easier on the eye.
Links: Changed how link underlining works by increasing the gap between the letters and underline. Makes the links look clearer. Also links now have a bit of tint when you hover which should make interacting with them nicer.

TIL: Number in man page titles (e.g. sleep(3))

Mon, 17 Nov 2025 13:10:00 +0000

If you do Linux systems programming, you will have likely pored over man pages, either on the command line or, my personal preference, using the excellent man7.org or linux.die.net. I’ve always seen the numbers in sleep(3) and read(2) and idly wondered what they meant, but never actually bothered to look them up.

That is, until a review comment on a pull request:

// Behaves like man 2 basename

reviewer: nit: it’s not a syscall, so “man 2” is incorrect

So I looked it up. The answer was in the man(1) page (also accessible via the delightful man man command):

The table below shows the section numbers of the manual followed by the types of pages they contain.
 1 Executable programs or shell commands
2 System calls (functions provided by the kernel)
3 Library calls (functions within program libraries)
(... less common section numbers)

So my colleague was right and the code should have read // behaves like man 3 basename as basename(3) is a libc library call.

And there’s more to these numbers than what the man man page describes: various letters can also be attached as suffixes to the numbers. For example, p indicates a POSIX man page like with free(3p) and x indicates X documentation like with ncurses(3x).

It’s embarrassing to admit I’ve been using man pages for years but only learned this today.

CAST(x AS STRING) casts to integer in SQLite

Mon, 03 Nov 2025 13:15:00 +0000

As an “SQLite consultant” for my local area of Google, I often have people come to me having written SQL like:

SELECT CAST(bar AS STRING) AS baz
FROM foo

and ask me “Why is baz always an integer?! Have I hit an SQLite bug?”.

I have to again reach for my list of “odd quirks that SQLite has that people don’t know about”. Because this is not a bug, at least according to the SQLite manual.

Instead, the correct way to write the above query is:

SELECT CAST(bar AS TEXT) AS baz
FROM foo

The reason for this? Quoting from “Determination of Column Affinity”

For tables not declared as STRICT, the affinity of a column is determined by the declared type of the column, according to the following rules in the order shown:

If the declared type contains the string “INT” then it is assigned INTEGER affinity.

If the declared type of the column contains any of the strings “CHAR”, “CLOB”, or “TEXT” then that column has TEXT affinity. Notice that the type VARCHAR contains the string “CHAR” and is thus assigned TEXT affinity.

If the declared type for a column contains the string “BLOB” or if no type is specified then the column has affinity BLOB.

If the declared type for a column contains any of the strings “REAL”, “FLOA”, or “DOUB” then the column has REAL affinity.

Otherwise, the affinity is NUMERIC.

STRING does not match any of the numbered rules and so fallback to NUMERIC affinity which, in the general case, means integer.

Due to SQLite’s staunch stance of being “backwards compatible” there’s very little chance of this paper-cut ever going away. But at least next time someone comes to me with this issue, I’ll be able to link to this post instead of writing the same thing for the nth time :)

TIL: Diátaxis: Systematic technical documentation

Sun, 02 Nov 2025 23:44:00 +0000

A few weeks ago, I wrote about “The Documentation System” and how valuable I found it. As I dug deeper into researching how best to apply the principles outlined there, I came across Diátaxis. Written by the same author after they left Divio, Diátaxis is a distillation of all the principles with much more guidance in how to apply the framework (e.g. giving more examples), diving more into the philosophy and in general being a more comprehensive view into how to write great technical docs.

I’m blown away by how well the framework (and Diátaxis makes clear it is a framework not a rigid set of rules) is explained. It’s patently obvious that the author really understands technical documentation and they truly have given a gift to the industry by writing it up.

Finding Diátaxis has only made me more motivated to deeply absorb its principles and see how to best apply it to all technical documentation I refactor and/or write going forward.

TIL: Public File Hosting with 0x0.st

Sat, 25 Oct 2025 15:13:00 +0100

Sometimes you run into a truly inspirational piece of software that it’s a wonder even exists. I found 0x0.st recently and it very much falls into this bucket.

It’s essentially a simple, no-account, temporary file hosting site where you can just upload a file using a simple HTTP POST and the site will host it for you for between 30 days and 1 year depending on the size of the file. Uploading a file is as simple as:

curl -F 'file=@yourfile.ext' https://0x0.st

and you’ll get back a URL that you can share or use in the future.

I thought all the services like this had long since disappeared especially in the age of increasing scrutiny by government of content that websites host. It turns out though that from this discussion on HN, there are actually a bunch of similar services (transfer.sh, bashupload.com, chunk.io) but 0x0.st was the only one which I was able to access without an error.

I’m particularly impressed by the transparency of the owner of 0x0.st about the challenges they face and how they deal with the problems of abuse, malware etc. Many of these are precisely what I thought were insurmountable of hosting a service like this but apparently there are people out there willing to overcome them!

TIL: `will-change` and `isolation` CSS properties

Fri, 24 Oct 2025 00:20:00 +0100

The Perfetto UI is a fascinating project to work on because it often faces performance problems which you wouldn’t see in more “normal” webapps. I learn about all sorts of weird web features by reviewing PRs for the UI.

Two such features I just learned about:

will-change (PR): a hint, to be used sparingly, to tell the browser that a certain property of a DOM element will change in the near future.
isolation (PR): I feel MDN didn’t do a great job of explaining so I asked Claude which gave a much more useful answer:

isolation is a CSS property that creates a new stacking context for an element. Think of a stacking context as a self-contained z-index universe. Elements within one stacking context can layer on top of each other, but their z-index values only matter relative to siblings within that same context.

TIL: The Documentation System (Divio)

Sun, 19 Oct 2025 19:38:00 +0100

The Perfetto team spent a lot of time earlier this year rewriting our documentation to be more useful for the average developer. We struggled a lot to figure out “what is the best way to structure our documentation”.

When reading Examples are the best documentation today, I came across The Documentation System, an approach to structuring developer documentation. Reading through it, I couldn’t help but marvel at how clear and concisely it laid out the ideas we were struggling to come up with from first principles.

Specifically, I really like how it breaks down documentation into four quadrants:

Tutorials: take your user through a series of steps to complete some task with your project.
How-to guides: solve a real world problem with your project.
Reference guides: give technical explanations of how things work.
Explanations: clarify a particular topic or area and how the project fits into the bigger tech landscape.

I think we got most of this right in our documentation rewrite but we definitely muddled some of these areas together, making our pages less clear than they could be. I plan on spending some time later this year correcting our docs to match this system closer.

What Makes a Good Tool for Claude Code

Sun, 12 Oct 2025 00:00:00 +0000

I’ve been using Claude Code extensively for personal projects, and similar AI coding tools at work. Recently I came across this excellent blog post that resonated with a lot of my experience.

One part stuck with me though: Noah emphasizes that tools fail with LLMs when they’re “overly complex,” with the Unix philosophy being particularly well-suited for tool calling. But then I thought about git.

Git breaks the Unix philosophy completely. It’s sprawling, stateful, and complex. And yet Claude Code handles it effortlessly. It composes commands that, even after 10+ years of daily git usage, I wouldn’t think to use. It handles rebasing, cherry-picking, complex resets—stuff that trips up experienced developers regularly.

So if simplicity and the Unix philosophy aren’t the whole story, what else matters?

I’ve come up with three “hallmarks” of a good tool for tool calling with LLMs.

1. It’s been around for a long time and/or is used by lots of people

Examples: Unix tools like cat, sed, awk, grep, find—but also git, npm, docker, kubectl. Every Stack Overflow thread, blog post, and tutorial using these tools has likely ended up in the training data. Claude isn’t reasoning from first principles—it’s drawing on millions of examples.

This is why git works despite its complexity: Claude has effectively memorized decades of collective wisdom.

2. It has really good documentation (built-in help or external docs)

Even if a tool isn’t widely used, great documentation can bridge the gap. I’ve been building a finance system on top of Beancount—a double-entry accounting system that’s definitely not mainstream (maybe I’ll write a post about this in the future). Claude Code handles it surprisingly well because Beancount has exceptional documentation. When I point Claude at the docs, it can figure out the directive syntax, transaction formats, and account structures without necessarily having seen millions of examples in its training data.

Good --help text matters. Clear external documentation matters. If Claude can discover how your tool works, it can use it effectively.

3. Good error messages

Error messages, especially those with suggestions like “you used X, did you mean Y?”, can be tremendously helpful for LLMs. The best example is the Rust compiler: it gives errors like “you typed foobar, did you mean foobaz?” and Claude Code can actually use that feedback to correct itself.

This might be one reason why people feel Claude Code is particularly good at Rust programming—the compiler is essentially coaching it through mistakes in real time.

This isn’t to say the Unix philosophy is wrong — it’s that Unix tools work well with Claude Code for different reasons than we might think. Tools like sed and awk nail hallmarks 1 and 2: they’ve been around for decades (massive training data) and have extensive man pages (great documentation). The fact that they follow “do one thing well” is almost incidental to their success with LLMs.

So if I’m building a tool today, I can’t make it instantly popular, but I can make it understandable. That means good documentation, clear error messages, and a few solid examples of how it’s used. Those aren’t new ideas — they’ve always mattered. The difference now is that there’s much higher ROI in doing them than there used to be.

In other words, we used to write docs for humans. Now, we’re also writing for AIs that help humans. That shift changes the economics of good documentation in a big way.

Harnessing Frustration: Using LLMs to Overcome Activation Energy

Mon, 14 Jul 2025 00:00:00 +0000

One of my biggest weaknesses as a software engineer is procrastination when facing a new project. When the scope is unclear, I have a tendency to wait until I feel I’ve “felt out” the problem to start doing anything. I know I’ll feel better and work much faster when I get “stuck in” but I still struggle with that first step, overcoming the “activation energy” required to engage with the details.

LLMs have been a game-changer for me in this respect: I can just throw a couple of sentences at them with the shape of the problem. This leads to one of two outcomes:

The LLM comes up with a good solution, usually in a slightly different way than what I was thinking. I realize “oh wow the solution is much simpler than I thought”. Straight away I start thinking about the consequences of implementing and improving what the LLM suggested.
The LLM comes up with a solution that I intuitively recognize as “wrong”. My immediate reaction is frustration (“How could it get it so wrong”) which leads me to go back and forth with the model, explaining to it why its solution could not possibly work. But in the process of arguing with the model, my brain is churning away and generating variations or different approaches that could work. After a while, even if the AI is still on the wrong track, the debate will trigger a moment of inspiration where suddenly the solution will come to me. I’ll excitedly start up a new conversation and start working through it with the model.

The key is the emotional reaction I have immediately to the LLM’s response, either excitement or frustration. By harnessing this immediate feedback loop, I get my brain out of its passive, procrastination mode. It’s almost like a jolt: either I’m thrilled because it’s simpler than I thought, or I’m spurred to action by the urge to correct a perceived ‘wrong’ answer. This forces me to engage with the problem in a meaningful way.

For what it’s worth, this experience is very similar to talking through a problem with another engineer: the advantage of LLMs is that it’s available 24/7 and I never have to worry about my problem being “too insignificant” to bother someone with. The simple act of articulating my thoughts and hearing a response seems sufficient, regardless of the response’s quality.

So next time you’re procrastinating a problem don’t wait around for inspiration. Outsource the first step. Throw the problem at an LLM and see what happens. Whether excitement or frustration, by channeling that emotion you can solve your problem faster.