# performance-engineering Published articles for performance-engineering. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Performance engineering as a habit, not a project DevFeed: [Performance engineering as a habit, not a project]() Original publisher: [Read original article]() Author: fidelitas.io Published: 2026-05-16T16:00:00Z Content type: tutorial Language: en Sources: [fidelitas.io]() Topics: [Benchmark](), [ci](), [Code](), [systems]() Tags: [benchmark](), [benchmarks](), [build](), [ci](), [cloud](), [code-review](), [engineering-practice](), [git](), [hardware](), [latency](), [observability](), [performance](), [performance-engineering](), [regression](), [runner](), [slo]() ### AI overview The article argues that teams should treat performance engineering as a recurring engineering habit rather than a temporary project. It recommends measuring every pull request, comparing results with the previous day, and making performance regressions fail the build as part of CI. ### Source excerpt Most performance work is reactive: the bill goes up, the dashboard turns red, somebody opens an investigation ticket. Here's how to make it boring instead. ## Continuous profiling at Mercado Libre: Turning flamegraphs into fixes DevFeed: [Continuous profiling at Mercado Libre: Turning flamegraphs into fixes]() Original publisher: [Read original article]() Author: Elton Hoffmann Published: 2026-03-11T01:27:33Z Content type: article Language: en Sources: [Mercado Libre Tech]() Topics: [observability](), [Tooling](), [Microservices](), [Latency](), [systems]() Tags: [ai](), [article](), [efficiency](), [end-user-experience](), [flamegraph](), [garbage-collection](), [latency](), [memory](), [microservices](), [observability](), [performance](), [performance-engineering](), [platform-engineering](), [profiling](), [uptime]() ### AI overview Mercado Libre describes building a continuous profiling platform for about 35,000 microservices. The platform treats profiling as an observability signal alongside metrics, logs, and traces, with the goal of helping teams detect performance issues and automate fixes for certain issue classes. ### Source excerpt We continue our series on Performance Engineering at Mercado Libre. In previous articles, we discussed how we crafted an observability culture across the company, how performance relates to other observability signals, and how the Performance Engineering team partners with Business Units to enhance platform efficiency. Today, we'll show how we built a continuous profiling platform for 35,000 microservices and how we started turning profiles into automated fixes. Context Our goal in the Performance Engineering team is threefold: to ensure uptime; to improve the end-user experience by reducing latency; to reduce computing costs. As a cross-functional team, we usually work with application owners to achieve these goals. In our two years of existence, our joint efforts have taken us through countless incidents and bottlenecks. Each problem is unique, but over time, we've seen some common patterns: high memory allocation, lack of garbage collection (GC) tuning, thread pool saturation, blocking I/O, and heavy workloads processing repeated tasks. Image 1: Typical flamegraph of high CPU usage replacing string patterns Trained eyes spot these signals quickly. But two eyeballs won't scale to thousands of services. Mercado Libre is an ever-growing company, with about 35,000 microservices, 30,000 deploys per day, and more than 16,000 people in IT roles. What are the odds that a performance issue found on one microservice doesn't exist in another? Or at least a similar issue? We often encounter systems with issues that are easy to fix but hard to detect (unless you have the right tools). It became clear we had to scale. We needed a platform-level solution that would let teams self-diagnose and self-tune. By the end of this article, you'll see how we built that and how we now automate both detection and fixes for certain classes of issues. Continuous profiling After setting our goal to improve performance tooling, we developed our own continuous profiling solution. Why profiling, ## Why I joined OpenAI DevFeed: [Why I joined OpenAI]() Original publisher: [Read original article]() Published: 2026-02-06T13:00:00Z Content type: opinion Language: en Sources: [Brendan Gregg's Blog]() Topics: [OpenAI](), [Artificial Intelligence](), [datacenter](), [ChatGPT]() Tags: [ai](), [ai-adoption](), [blog](), [chatgpt](), [datacenter](), [openai](), [performance-engineering]() ### AI overview The author explains joining OpenAI to work on datacenter and ChatGPT performance, motivated by the rapidly growing cost and scale of AI infrastructure. The article also describes conversations that changed the author's view of how widely people use ChatGPT in everyday life. ### Source excerpt The staggering and fast-growing cost of AI datacenters is a call for performance engineering like no other in history; it's not just about saving costs - it's about saving the planet. I have joined OpenAI to work on this challenge directly, with an initial focus on ChatGPT performance. The scale is extreme and the growth is mind-boggling. As a leader in datacenter performance, I've realized that performance engineering as we know it may not be enough - I'm thinking of new engineering methods so that we can find bigger optimizations than we have before, and find them faster. It's the opportunity of a lifetime and, unlike in mature environments of scale, it feels as if there are no obstacles - no areas considered too difficult to change. Do anything, do it at scale, and do it today. Why OpenAI exactly? I had talked to industry experts and friends who recommended several companies, especially OpenAI. However, I was still a bit cynical about AI adoption. Like everyone, I was being bombarded with ads by various companies to use AI, but I wondered: was anyone actually using it? Everyday people with everyday uses? One day during a busy period of interviewing, I realized I needed a haircut (as it happened, it was the day before I was due to speak with Sam Altman). Mia the hairstylist got to work, and casually asked what I do for a living. "I'm an Intel fellow, I work on datacenter performance." Silence. Maybe she didn't know what datacenters were or who Intel was. I followed up: "I'm interviewing for a new job to work on AI datacenters." Mia lit up: "Oh, I use ChatGPT all the time!" While she was cutting my hair - which takes a while - she told me about her many uses of ChatGPT. (I, of course, was a captive audience.) She described uses I hadn't thought of, and I realized how ChatGPT was becoming an essential tool for everyone. Just one example: She was worried about a friend who was travelling in a far-away city, with little timezone overlap when they could chat, but she c ## When to Hire a Computer Performance Engineering Team (2025) part 1 of 2 DevFeed: [When to Hire a Computer Performance Engineering Team (2025) part 1 of 2]() Original publisher: [Read original article]() Published: 2025-08-03T14:00:00Z Content type: tutorial Language: en Sources: [Brendan Gregg's Blog]() Topics: [benchmarking](), [Latency](), [Scalability](), [Development]() Tags: [blog](), [infrastructure](), [intel](), [latency](), [netflix](), [observability](), [performance](), [performance-engineering](), [scalability]() ### AI overview This advice article explains what computer performance engineering teams do and when technology companies should consider forming one. It describes potential benefits including infrastructure cost savings, lower latency, improved scalability and reliability, and faster engineering, with a focus on non-vendor companies using significant back-end compute and AI. ### Source excerpt As a leader in computer performance I've been asked by companies about how (and why) to form a performance engineering team, and as this is broadly useful I'll share my advice here. Large tech companies in the US hire performance engineers (under that or other titles) to ensure that infrastructure costs and service latency don't grow too high, and that their service is reliable under peak load. A new performance team can likely find enough optimizations to halve infrastructure spend in their first couple of years, even for companies that have been using commercial performance or observability tools. Performance engineers do much more than those tools, working with development teams and vendors to build, test, debug, tune, and adopt new performance solutions, and to find deep optimizations that those tools can miss. I previously worked on the performance engineering team for Netflix, a large tech consumer running on hundreds of thousands of AWS instances. I'm now doing similar work at Intel (a large tech vendor) for Intel and their customers. As a leader in this space I've also interacted with other performance teams and staff doing performance work at many companies. In this post I'll explain what these teams do and when you should consider forming one. In part 2 I'll provide sample job descriptions, specialties, advice, pitfalls, comments on AI, and what to do if you can't hire a performance team. It's easy for hardware vendors like Intel to justify hiring performance engineers, as the number one factor in sales is beating a competitor's performance. However, my focus in this post is on non-vendor tech-heavy companies who hire these staff to drive down costs and latency outliers (e.g., banks, telecomms, defence, AI, tech-based companies, and anyone else who is spending more than $1M/year on back-end compute and AI). What is the ROI of performance engineering? The main ROIs are infrastructure cost savings, latency reductions, improved scalability and reliability, an ## 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. ## 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. ## Public Tech Talk on Modern Exchange Architecture DevFeed: [Public Tech Talk on Modern Exchange Architecture]() Original publisher: [Read original article]() Author: Yaron Minsky Published: 2017-01-11T00:00:00Z Content type: article Language: en Sources: [Jane Street]() Topics: [Architecture & Design](), [systems](), [Latency](), [Replication]() Tags: [architecture](), [latency](), [performance-engineering](), [replication](), [talk]() ### AI overview Jane Street announces a public tech talk about the architecture of a modern exchange, inspired by its JX crossing engine. The post discusses how high-throughput, low-deterministic-latency components and reliable multicast replication can simplify system design. ### Source excerpt UPDATE: We are full up. Tons of people signed up for the talk, and we're now at the limit of what we feel like we can support in the space. Thanks for all the interest, and if you didn't get into this one, don't worry, we have more talks coming!