# Nelson Elhage Recent content in Posts on Made of Bugs This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## From error-handling to structured concurrency DevFeed: [From error-handling to structured concurrency]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2026-03-23T15:30:00Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [Concurrency](), [Concurrent Programming](), [Error Handling](), [Exception]() Tags: [concurrency](), [error-handling](), [examples](), [exception](), [exception-handling](), [structured-concurrency]() ### AI overview This article examines how error-handling patterns based on stack unwinding and cleanup should be adapted for concurrent programs with multiple tasks. It introduces the problem of unhandled errors in concurrent execution and compares possible behaviors when one task fails. ### Source excerpt How should we think about error-handling in concurrent programs? In single-threaded programs, we've mostly converged on a standard pattern, with a diverse zoo of implementations and concrete patterns. When an error occurs, it is propagated up the stack until we find a stack frame which is prepared to handle it. As we do so, we unwind the stack frames in-order, giving each frame the opportunity to clean up or destroy resources as appropriate. ## Solving regex crosswords with Z3 DevFeed: [Solving regex crosswords with Z3]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2025-10-21T14:00:00Z Content type: tutorial Language: en Sources: [Nelson Elhage]() Topics: [Regular expression](), [Automaton](), [Finite-state machine](), [Python]() Tags: [code](), [dfa](), [experimentation](), [performance](), [python](), [regex]() ### AI overview This technical post explains how to solve regular-expression crossword puzzles with a Z3-backed solver. It describes encoding regular expressions as deterministic finite automata, using a Python library to convert regex syntax to finite-state machines, and exploring solver performance and implementation improvements. ### Source excerpt For a while now, I've been fascinated by Z3 and by SMT solving more broadly. While on pat leave recently, I was reminded of the existence of regular-expression crossword puzzles, and allowed myself to get nerdsniped by writing a Z3-backed solver. I expected to spend perhaps an afternoon cranking out a quick solver; I ended up getting sucked into understanding and debugging Z3 performance, and learning far more about Z3 and about SMT than I expected. ## The ITTAGE indirect branch predictor DevFeed: [The ITTAGE indirect branch predictor]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2025-07-04T21:30:00Z Content type: article Language: en Sources: [Nelson Elhage]() Topics: [cpu](), [Python](), [Algorithm](), [Python 3.14]() Tags: [algorithm](), [bytecode](), [cpu](), [performance](), [python](), [python-3-14]() ### AI overview An explanatory article about ITTAGE indirect branch prediction and how modern CPUs predict bytecode-dispatch jumps. It connects the topic to Python 3.14's tail-calling interpreter and describes ITTAGE as a TAGE variant that predicts indirect jump destinations using program-counter history and multiple history-length tables. ### Source excerpt While investigating the performance of the new Python 3.14 tail-calling interpreter, I learned (via this very informative comment from Sam Gross) new (to me) piece of performance trivia: Modern CPUs mostly no longer struggle to predict the bytecode-dispatch indirect jump inside a "conventional" bytecode interpreter loop. In steady-state, assuming the bytecode itself is reasonable stable, modern CPUs achieve very high accuracy predicting the dispatch, even for "vanilla" while / switch-style interpreter loops1! ## Performance of the Python 3.14 tail-call interpreter DevFeed: [Performance of the Python 3.14 tail-call interpreter]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2025-03-09T22:00:00Z Content type: article Language: en Sources: [Nelson Elhage]() Topics: [Python 3.14](), [benchmarking](), [gcc](), [LLVM](), [Software Engineering]() Tags: [benchmark](), [benchmarking](), [benchmarks](), [bytecode](), [clang](), [compilers](), [cpu](), [gcc](), [intel](), [llvm](), [performance](), [performance-engineering](), [python](), [python-3-14](), [software-engineering]() ### AI overview This article examines the performance gains attributed to CPython's Python 3.14 tail-call bytecode interpreter. It finds that the initial 10-15% improvement was primarily caused by inadvertently working around an LLVM 19 regression; with better baselines, the gain is closer to 1-5%, depending on the setup. ### Source excerpt About a month ago, the CPython project merged a new implementation strategy for their bytecode interpreter. The initial headline results were very impressive, showing a 10-15% performance improvement on average across a wide range of benchmarks across a variety of platforms. Unfortunately, as I will document in this post, these impressive performance gains turned out to be primarily due to inadvertently working around a regression in LLVM 19. When benchmarked against a better baseline (such GCC, clang-18, or LLVM 19 with certain tuning flags), the performance gain drops to 1-5% or so depending on the exact setup. ## Building personal software with Claude DevFeed: [Building personal software with Claude]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2025-01-27T20:00:00Z Content type: article Language: en Sources: [Nelson Elhage]() Topics: [Claude](), [Rust](), [Emacs](), [Obsidian](), [Software Engineering](), [JSON](), [Markdown](), [Org mode]() Tags: [app](), [claude](), [code](), [emacs](), [json](), [markdown](), [profiling](), [rust](), [software]() ### AI overview The author describes using Claude, under supervision, to port parts of an Emacs package from Elisp to Rust. The resulting approach reduced one measured execution time from about 90 seconds to 15 milliseconds and changed the author's view of LLMs' role in software engineering. ### Source excerpt Earlier this month, I used Claude to port (parts of) an Emacs package into Rust, shrinking the execution time by a factor of 1000 or more (in one concrete case: from 90s to about 15ms). This is a variety of yak-shave that I do somewhat routinely, both professionally and in service of my personal computing environment. However, this time, Claude was able to execute substantially the entire project under my supervision without me writing almost-any lines of code, speeding up the project substantially compared to doing it by hand. ## Finding near-duplicates with Jaccard similarity and MinHash DevFeed: [Finding near-duplicates with Jaccard similarity and MinHash]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2024-07-03T23:00:00Z Content type: tutorial Language: en Sources: [Nelson Elhage]() Topics: [dataset](), [Website]() Tags: [dataset](), [pairs](), [pipeline](), [range](), [scale]() ### AI overview This article explains approximate document deduplication using Jaccard similarity and the MinHash approximation technique. It discusses defining similarity between document pairs, setting a threshold for approximate duplicates, and why approximate similarity is not transitive. ### Source excerpt Suppose we have a large collection of documents, and we wish you identify which documents are approximately the same as each other. For instance, we may have crawled the web over some period of time, and expect to have fetched the "same page" several times, but to see slight differences in metadata, or that we have several revisions of a page following small edits. In this post I want to explore the method of approximate deduplication via Jaccard similarity and the MinHash approximation trick. ## Stripe's monorepo developer environment DevFeed: [Stripe's monorepo developer environment]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2024-05-21T17:00:00Z Content type: article Language: en Sources: [Nelson Elhage]() Topics: [monorepo](), [Developer experience](), [code productivity](), [Tooling](), [Ruby](), [Development]() Tags: [developer](), [developer-experience](), [developer-productivity](), [development](), [monorepo](), [ruby](), [stripe](), [tooling]() ### AI overview A former Stripe engineer recalls the company's developer environment from 2012 to 2019, focusing on tooling used to develop and test code in a large Ruby monorepo. The account explains that these choices were shaped by Stripe's business and technical context and may not reflect the company's current environment. ### Source excerpt I worked at Stripe for about seven years, from 2012 to 2019. Over that time, I used and contributed to many generations of Stripe's developer environment - the tools that engineers used daily to write and test code. I think Stripe did a pretty good job designing and building that developer experience, and since leaving, I've found myself repeatedly describing features of that environment to friends and colleagues. This post is an attempt to record the salient features of that environment as I remember it. ## Performance engineering, profilers, and seeing the invisible DevFeed: [Performance engineering, profilers, and seeing the invisible]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2023-12-18T16:00:00Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [Software](), [Tool](), [coding]() Tags: [engineering](), [paper](), [performance](), [performance-engineering](), [software](), [tools]() ### AI overview The article examines performance engineering through the idea that experts can perceive information absent from direct observation. It argues that profilers show where a particular program execution spends time, but effective optimization also requires understanding context and information not present in the profile. ### Source excerpt I was recently introduced to the paper "Seeing the Invisible: Perceptual-Cognitive Aspects of Expertise" by Gary Klein and Robert Hoffman. It's excellent and I recommend you read it when you have a chance. Klein and Hoffman discuss the ability of experts to "see what is not there": in addition to observing data and cues that are present in the environment, experts perceive implications of these cues, such as the absence of expected or "typical" information, the typicality or atypicality of observed data, and likely/possible past and future time trajectories of a system based on a point-in-time snapshot or limited duration of observation. ## Advent of Code in C++ Template Metaprogramming DevFeed: [Advent of Code in C++ Template Metaprogramming]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2023-12-08T15:30:00Z Content type: tutorial Language: en Sources: [Nelson Elhage]() Topics: [Advent of Code](), [C++](), [Code](), [Compiler](), [polyfill]() Tags: [advent-of-code](), [c-plus-plus](), [code](), [compiler](), [polyfill](), [writeup]() ### AI overview An annotated walkthrough of solving the first Advent of Code problem using purely compile-time C++ template metaprogramming. It covers compile-time input handling, folds, helper types, and state tracking to calculate calibration values. ### Source excerpt This December, the imp of the perverse struck me, and I decided to see how many days of Advent of Code I could do purely in compile-time C++ metaprogramming. As of this writing, I've done two days, and I'm not sure I'll make it any further. However, that's one more day than I planned to do as of yesterday, which is in turn further than I thought I'd make it after my first attempt. ## Why Python pickle remains common in machine-learning software DevFeed: [Why Python pickle remains common in machine-learning software]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2023-11-08T05:00:00Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [Machine Learning & Artificial Intelligence](), [Python](), [Software](), [Security](), [upgrade]() Tags: [machine-learning](), [ml](), [python](), [security](), [software](), [upgrade]() ### AI overview The author examines why Python pickle is widely used in machine-learning software despite security concerns and brittle serialization. The article argues that ML software is shaped by research workflows, where teams prioritize exploring ideas and producing knowledge over maintaining durable software artifacts. ### Source excerpt I have spent many years as an software engineer who was a total outsider to machine-learning, but with some curiosity and occasional peripheral interactions with it. During this time, a recurring theme for me was horror (and, to be honest, disdain) every time I encountered the widespread usage of Python pickle in the Python ML ecosystem. In addition to their major security issues1, the use of pickle for serialization tends to be very brittle, leading to all kinds of nightmares as you evolve your code and upgrade libraries and Python versions. ## Service Performance at Capacity: Request Rate, Throughput, and Graceful Behavior DevFeed: [Service Performance at Capacity: Request Rate, Throughput, and Graceful Behavior]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2023-08-07T16:00:00Z Content type: article Language: en Sources: [Nelson Elhage]() Topics: [systems](), [servers](), [web applications](), [Back end](), [TCP/IP](), [Firewall](), [Networks](), [Python]() Tags: [architecture](), [backend](), [capacity](), [firewall](), [http](), [network](), [performance](), [python](), [tcp-ip]() ### AI overview The article examines service performance by relating incoming request rate to successful throughput. It introduces these metrics through examples involving an HTTP web application and a TCP/IP router or firewall. ### Source excerpt Suppose we've got a service. We'll gloss over the details for now, but let's stipulate that it accepts requests from the outside world, and takes some action in response. Maybe those requests are HTTP requests, or RPCs, or just incoming packets to be routed at the network layer. We can get more specific later. What can we say about its performance? All we know is that it receives requests, and that it acts on them. ## Efficiency trades off against resiliency DevFeed: [Efficiency trades off against resiliency]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2023-04-15T23:00:00Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [Resilience](), [Monitoring](), [Server]() Tags: [cpu](), [efficiency](), [monitoring](), [performance](), [resiliency](), [work]() ### AI overview The article examines how maximizing CPU utilization can leave servers without capacity to absorb unexpected traffic or added workload. It argues that improving efficiency often requires tradeoffs with resilience, while noting that some performance fixes can improve both. ### Source excerpt What's the "right" level of CPU utilization for a server? If you look at a monitoring dashboard from a well-designed and well-run service, what CPU utilization should we hope to see, averaged over a day or two? It's a very general question, and it's not clear it should have a single answer. That said, for a long time, I generally believed that higher is always better: we should aim for as close to 100% utilization as we can. ## Transformers for software engineers DevFeed: [Transformers for software engineers]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2022-04-01T20:00:00Z Content type: tutorial Language: en Sources: [Nelson Elhage]() Topics: [Transformer architecture](), [Programming](), [Software Engineering](), [Reverse Engineering](), [Transformers]() Tags: [anthropic](), [architecture](), [codex](), [deep-learning](), [gpt-3](), [model-architecture](), [programming](), [reverse-engineering](), [software-engineering](), [storm](), [transformer-architecture](), [transformers]() ### AI overview This tutorial explains Transformer architecture for software engineers, using software engineering and programming perspectives to discuss how GPT-style Transformer models work. It also connects the architecture to interpretability and reverse-engineering efforts. ### Source excerpt Ever since its introduction in the 2017 paper, Attention is All You Need, the Transformer model architecture has taken the deep-learning world by storm. Initially introduced for machine translation, it has become the tool of choice for a wide range of domains, including text, audio, video, and others. Transformers have also driven most of the massive increases in model scale and capability in the last few years. OpenAI's GPT-3 and Codex models are Transformers, as are DeepMind's Gopher models and many others. ## A Rare, Nondeterministic RDMA Bug in Large Distributed Training Jobs DevFeed: [A Rare, Nondeterministic RDMA Bug in Large Distributed Training Jobs]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2022-02-23T03:03:48Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [bug](), [distributed-systems](), [distributed-training](), [Processes](), [coding]() Tags: [bug](), [code](), [debugging](), [distributed-systems](), [distributed-training](), [process](), [processes](), [python](), [rdma]() ### AI overview An Anthropic engineer describes a rare, nondeterministic bug in very large distributed training jobs. The bug originated in the RDMA software stack and caused subprocess launches to fail on a small fraction of nodes, sometimes producing Python exceptions or segmentation faults. ### Source excerpt In my day job at Anthropic, we run relatively large distributed systems to train large language models. One of the joys of using a lot of computing resources, especially on somewhat niche software stacks, is that you spend a lot of time running into the long-tail of bugs which only happen rarely or in very unusual configurations, which you happen to be the first to encounter. These bugs are frustrating, but I also often enjoy them. ## Distributed cloud builds for everyone DevFeed: [Distributed cloud builds for everyone]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2021-05-31T23:05:17Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [cloud-computing](), [AWS Lambda](), [Development](), [Open Source]() Tags: [aws-lambda](), [build](), [cloud](), [cloud-computing](), [compilation](), [compute](), [distributed](), [ec2](), [github-actions](), [open-source](), [software-development]() ### AI overview This opinion article presents Llama as a design for making distributed cloud builds more accessible to individual developers and smaller open-source projects. It discusses AWS Lambda, cost scaling, and the potential for cloud compilation to become a common development workflow. ### Source excerpt CPU cycles are cheaper than they have ever been, and cloud computing has never been more ubiquitous. All the major cloud providers offer generous free tiers, and services like GitHub Actions offer free compute resources to open-source repositories. So why do so many developers still build software on their laptops? Despite the embarrassment of riches of cheap or even free cloud compute, most projects I know of, and most developers, still do most of their software development -- building and running code -- directly on their local machines. ## Building LLVM in 90 seconds using Amazon Lambda DevFeed: [Building LLVM in 90 seconds using Amazon Lambda]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2021-05-21T02:00:28Z Content type: article Language: en Sources: [Nelson Elhage]() Topics: [LLVM](), [llama](), [amazon](), [Amazon S3](), [C++](), [C](), [Compiler]() Tags: [amazon](), [c](), [c-plus-plus](), [compilation](), [compiler](), [compute](), [llama](), [llvm](), [optimization](), [s3]() ### AI overview The article describes Llama, a tool that offloads C and C++ compilation to Amazon Lambda. In the reported test, a stripped-down clang and LLVM build completed in about 80 seconds on a 12-core, 24-thread AMD Ryzen 9 3900 system, at an estimated cost of around forty cents. ### Source excerpt Last week, Frederic Cambus wrote about building LLVM quickly on some very large machines, culminating in a 2m37s build on a 160-core ARM machine. I don't have a giant ARM behemoth, but I have been working on a tool I call Llama, which lets you offload computational work - including C and C++ builds - onto Amazon Lambda. I decided to see how good it could do at a similar build. ## Some opinionated thoughts on SQL databases DevFeed: [Some opinionated thoughts on SQL databases]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2021-03-30T17:32:31Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [Databases](), [SQL](), [MySQL](), [PostgreSQL](), [SQLite](), [backends](), [Web APIs](), [Latency]() Tags: [acid](), [backends](), [consistency](), [databases](), [durability](), [high-availability](), [low-latency](), [mysql](), [open-source](), [postgresql](), [sql](), [sqlite](), [web-apis]() ### AI overview An opinionated discussion of SQL databases, focused mainly on MySQL and PostgreSQL, with some coverage of SQLite. Drawing on experience using databases as backends for web applications and APIs, the article argues that open-source SQL databases provide excellent storage engines, throughput, durability, and transactional guarantees when properly tuned. ### Source excerpt People who work with me tend to realize that I have Opinions about databases, and SQL databases in particular. Last week, I wrote about a Postgres debugging story and tweeted about AWS' policy ban on internal use of SQL databases, and had occasion to discuss and debate some of those feelings on Twitter; this article is an attempt to write up more of them into a single place I can refer to. ## Towards solving Ultimate Tic Tac Toe DevFeed: [Towards solving Ultimate Tic Tac Toe]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2020-07-15T17:15:21Z Content type: article Language: en Sources: [Nelson Elhage]() Topics: [Algorithms](), [Rust](), [Programming]() Tags: [algorithms](), [experience](), [game-theory](), [games](), [parallel](), [performance](), [programming](), [rust](), [strategy]() ### AI overview The article describes an ongoing effort to solve Ultimate Tic Tac Toe by developing a minimax AI and investigating algorithms from combinatorial game theory. The project also provided experience with Rust and high-performance parallel programming, but the game had not yet been solved. ### Source excerpt Summary: Read about my efforts to solve the game of Ultimate Tic Tac Toe. It's been a fun journey into interesting algorithms and high-performance parallel programming in Rust. Backstory Starting around the beginning of the COVID-19 lockdown, I've gotten myself deeply nerdsniped by an attempt to solve the game of Ultimate Tic Tac Toe, a two-level Tic Tac Toe variant which is (unlike Tic Tac Toe) nontrivial and contains some interesting strategic elements. ## Write testable code by writing generic code DevFeed: [Write testable code by writing generic code]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2020-03-12T01:30:17Z Content type: article Language: en Sources: [Nelson Elhage]() Topics: [Testing](), [Amazon S3](), [Code](), [Software Engineering]() Tags: [code](), [s3](), [software](), [software-testing](), [testing]() ### AI overview The article examines how to make difficult error-handling behavior easier to test by generalizing a specific S3 connection-reset problem into a generic retryable stream abstraction. The supplied text describes restarting reads from the current byte offset using S3 range requests. ### Source excerpt Alex Gaynor recently asked this question in an IRC channel I hang out in (a channel which contains several software engineers nearly as obsessed with software testing as I am): uhh, so I'm writing some code to handle an econnreset... how do I test this? This is a good question! Testing ECONNRESET is one of those fiddly problems that exists at the interface between systems -- in his case, with S3, not even a system under his control -- that can be infuriatingly tricky to reproduce and test. ## Test suites as classifiers DevFeed: [Test suites as classifiers]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2020-03-01T20:34:00Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [test](), [Code](), [Development](), [bug](), [incident]() Tags: [bug](), [code](), [development](), [incident](), [patches](), [test](), [tests]() ### AI overview The article presents a test suite as a classifier that evaluates whether code changes are acceptable to apply and deploy. It explains that test results can produce false alarms or missed alarms, whose costs differ: missed alarms may allow bugs to reach production, while false alarms slow development. ### Source excerpt Suppose we have some codebase we're considering applying some patch to, and which has a robust and maintained test suite. Considering the patch, we may ask, is this patch acceptable to apply and deploy. By this we mean to ask if the patch breaks any important functionality, violates any key properties or invariants of the codebase, or would otherwise cause some unacceptable risk or harm. In principle, we can divide all patches into "acceptable" or "unacceptable" relative to some project-specific notion of what we're willing to allow. ## Systems that defy detailed understanding DevFeed: [Systems that defy detailed understanding]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2020-02-22T20:00:00Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [systems](), [distributed-systems](), [debugging](), [incident]() Tags: [debugging](), [distributed-systems](), [incident](), [software](), [stripe](), [systems]() ### AI overview The article argues that pursuing detailed explanations is not always the best strategy for dealing with complex systems. It focuses on distributed systems, where component and network failures make complete understanding difficult or impractical, and contrasts investigating root causes with improving fault-tolerance mechanisms such as retries and timeouts. ### Source excerpt Last week, I wrote about the mindset that computer systems can be understood, and behaviors can be explained, if we're willing to dig deep enough into the stack of abstractions our software is built atop. Some of the ensuing discussion on Twitter and elsewhere lead me to write this followup, in which I want to run through a few classes of systems where I've found pursuing in-detail understanding of the system wasn't the right answer. ## Computers can be understood DevFeed: [Computers can be understood]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2020-02-16T20:00:00Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [Software](), [systems](), [coding]() Tags: [abstraction](), [architecture](), [browser](), [compilers](), [complexity](), [concepts](), [cpu](), [exploration](), [hardware](), [javascript](), [kernel](), [learning](), [software](), [systems]() ### AI overview The author describes a mindset centered on the belief that computers and software systems can be understood through determined exploration and learning. Although modern systems are highly complex and layered, each layer can be understood at an appropriate level of abstraction, with deeper investigation possible when needed. ### Source excerpt Introduction This post attempts to describe a mindset I've come to realize I bring to essentially all of my work with software. I attempt to articulate this mindset, some of its implications and strengths, and some of the ways in which it's lead me astray. Software can be understood I approach software with a deep-seated belief that computers and software systems can be understood. This belief is, for me, not some abstruse theoretical assertion, but a deeply felt belief that essentially any question I might care to ask (about computers) has a comprehensible answer which is accessible with determined exploration and learning. ## Reflections on software performance DevFeed: [Reflections on software performance]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2020-02-03T01:00:00Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [Software](), [coding]() Tags: [blog](), [performance](), [reflections](), [software]() ### AI overview A reflection on lessons learned from building and using performant software. The article argues that performance is a feature that affects how software is perceived and used, and that making tools faster enables users to pursue tasks more frequently and in new ways. ### Source excerpt At this point in my career, I've worked on at least three projects where performance was a defining characteristic: Livegrep, Taktician, and Sorbet (I discussed sorbet in particular last time, and livegrep in an earlier post). I've also done a lot of other performance work on the tools I use, some of which ended up on my other blog, Accidentally Quadratic. In this post, I want to reflect on some of the lessons I've learned while writing performant software, and working with rather a lot more not-so-performant software. ## Why the Sorbet typechecker is fast DevFeed: [Why the Sorbet typechecker is fast]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2020-01-24T01:00:00Z Content type: article Language: en Sources: [Nelson Elhage]() Topics: [Ruby](), [C++](), [Data structures](), [Architecture & Design](), [cpu](), [Software Engineering]() Tags: [c-plus-plus](), [cpu](), [data-structures](), [performance](), [ruby](), [software-design]() ### AI overview This article explains why the Sorbet Ruby typechecker is fast. It attributes the performance to C++, native-code compilation, explicit data-structure and allocation control, and designs that improve CPU cache locality. Informal benchmarks on Stripe's codebase measured about 100,000 lines of code typechecked per second per core. ### Source excerpt This is the second in an indefinite series of posts about things that I think went well in the Sorbet project. The previous one covered our testing approach. Sorbet is fast. Numerous of our early users commented specifically on how fast it was, and how much they appreciated this speed. Our informal benchmarks on Stripe's codebase clocked it as typechecking around 100,000 lines of code per second per core, making it one of the fastest production typecheckers we are aware of. [Next page]()