标签：#performance

The problem with "just add more workers" Most Spark performance issues on Databricks aren't solved by scaling the cluster — they're caused by shuffle and skew , and no amount of extra nodes fixes a badly partitioned join. This post builds a realistic pipeline (order events joined against a small dimension table, aggregated, and written to Delta Lake) from the ground up, and uses it to work through: How Spark's shuffle actually behaves during a wide transformation Diagnosing and fixing data skew with salting and adaptive query execution (AQE) Laying out the resulting Delta table with Z-Ordering so downstream queries skip irrelevant files Governing access to the whole pipeline with Unity Catalog Architecture overview Pipeline shape — a batch job reading raw events, joining against a dimension table, aggregating, and writing to a governed Delta table: What happens inside a shuffle stage — this is the part most tutorials skip, and it's the key to understanding why skew hurts: Step 1 — Set up governed tables in Unity Catalog Everything downstream depends on tables being registered under Unity Catalog, which gives you centralized access control and lineage instead of per-workspace table grants. -- setup.sql, run in a Databricks SQL or notebook cell CREATE CATALOG IF NOT EXISTS retail_analytics ; CREATE SCHEMA IF NOT EXISTS retail_analytics . events ; CREATE TABLE IF NOT EXISTS retail_analytics . events . raw_orders ( order_id STRING , customer_id STRING , product_id STRING , quantity INT , event_ts TIMESTAMP ) USING DELTA LOCATION 'abfss://data@<storage-account>.dfs.core.windows.net/raw_orders' ; CREATE TABLE IF NOT EXISTS retail_analytics . events . dim_products ( product_id STRING , category STRING , unit_cost DOUBLE ) USING DELTA LOCATION 'abfss://data@<storage-account>.dfs.core.windows.net/dim_products' ; GRANT SELECT ON TABLE retail_analytics . events . raw_orders TO `analysts` ; Step 2 — Read and force a broadcast join for the small dimension table dim_products is s

Headline: Next.js Middleware (middleware.ts at the project root) runs before every matched request — before cache, before rendering, before the route. That position makes it right for auth redirects, A/B cookie bucketing, and locale detection. Wrong for database queries and heavy imports. In 2026, Middleware on Vercel runs on Fluid Compute (standard Node.js), so the constraint is latency budget, not API availability. Key takeaways Middleware runs before every matched request — before cache, rendering, or route handler — the right layer for auth, locale, and A/B bucketing. Middleware can read requests, set cookies, redirect, rewrite, or return early — without the route running. DB queries and large packages add latency to every request. On Vercel in 2026, Middleware runs on Fluid Compute (standard Node.js). The constraint is latency: every added millisecond is paid on every matched request. Use matcher to scope Middleware to only the routes that need it; without it Middleware runs on every static asset request. Auth in Middleware = verifying a self-contained JWT without a DB call. Full session validation belongs in the route. I spent a long time only using Middleware for locale redirects. After shipping auth-protected routes and an A/B test, the full shape became clear. What is Next.js Middleware and where does it run? Middleware is exported from middleware.ts at the project root. It intercepts matched requests before route resolution, cache lookup, and Server Component execution. Returns one of four types: pass through ( NextResponse.next() ), redirect, rewrite (serve different content while keeping original URL in address bar), or a direct response. export function middleware ( request : NextRequest ) { return NextResponse . next (); } export const config = { matcher : [ ' /((?!_next/static|_next/image|favicon.ico).*) ' ], }; Without matcher , Middleware runs on every request including static files. On Vercel in 2026, Middleware runs on Fluid Compute — standard Nod

Have you ever noticed that your GenAI applications are spending massive amounts of time and money re-reading the exact same setup text? Every time a user asks a short question in a chatbot, the Large Language Model (LLM) must re-read your entire 2,000-word corporate playbook, your agent's system rules, and the full chat history from scratch. This phase is called the pre-fill math phase, and it drives up both your cloud bill and your user latency (Time-to-First-Token).With Amazon Bedrock Prompt Caching for Claude 4.6 (both Sonnet 4.6 and Opus 4.6), this problem is completely solved. You can achieve up to a 90% cost reduction on input tokens and an 85% drop in latency by using a clever architectural shortcut. Here is exactly how it works under the hood, how AWS maintains it across API requests, and how to implement it using Python. The Secret Architecture: Model Inference vs. AWS Infrastructure Prompt caching is a beautiful team effort between the AI model hardware and the AWS cloud infrastructure. The Model Level (The Brains): Inside Claude 4.6, text is processed through mathematical matrices called KV (Key-Value) Caches. Instead of re-reading text, the GPUs calculate the meaning of your system instructions once and build a "mathematical profile." When a cache point is triggered, the model freezes this calculated KV state inside the GPU memory. 2.The AWS Bedrock Level (The Manager): Normally, an LLM wipes its memory the millisecond an API call finishes. AWS Bedrock changes this. It takes your static prompt, creates a secure, unique cryptographic hash (fingerprint), and pins that KV memory block alive. When your next API request comes in, AWS Bedrock instantly hashes the new incoming prompt text. If the top section matches a saved fingerprint, Bedrock's router bypasses the standard pre-fill setup and routes your request directly to the GPU holding your frozen mathematical profile. It is exactly like loading a "Save Game" file instead of restarting a video game from Le

"You're spawning a fresh codex exec for every single call? Just run the app-server and reuse a thread. The prompt cache alone will pay for it." That sentence sounds so obviously right that nobody ever benchmarks it. We run a small bazaar of headless AI daemons — designers, reviewers, code workers — and each one shells out to OpenAI's Codex CLI dozens of times per work item. A resident codex app-server --stdio with warm threads looked like free money. We measured it four times. The prompt cache eventually hit 86% on the turns that mattered. The pipeline got slower than the boring baseline, and 39% more expensive in raw tokens. This is the story of why, and of what app-server is actually for. The setup was deliberately minimal: no resident daemon, no pool. The server is spawned privately for one formation , runs its turns, and is killed by a context manager on the way out — success or crash. That keeps the comparison honest: same lifecycle as a subprocess, and adopting it stays a measurement problem instead of an architecture debate. Trusting the probe Before writing any integration, we cloned the actual openai/codex source and pointed a probe at a real app-server: handshake, per-turn sandbox overrides, interrupts, forks, kill-and-resume. Eight checks, all green, plus three findings you won't find in any docs: cwd and sandboxPolicy are sticky when omitted — every turn must re-state them explicitly, or turn 3 silently inherits turn 2's write access. Token usage arrives on thread/tokenUsage/updated , not on turn/completed . An empty thread that never ran a turn is never materialized — you cannot resume it later. Pre-warming a thread pool is a trap. And the seductive one: on the probe's trivial two-turn thread, turn 2 reported 15,104 cached input tokens . See? The cache works. Ship it. That number cost us three more measurement runs to un-believe. The four runs Same fixture repo, same greenfield request, one real four-stage formation each: A: codex exec (baseline) B: app

Most ad-hoc timing code in Python looks like this: start = time . perf_counter () result = do_work () elapsed = time . perf_counter () - start stats [ name ]. append ( elapsed ) It works, until do_work() raises. Then the line that records the timing never runs, the exception propagates, and the one call that was probably slowest — the one that failed — is silently missing from your stats. If you're using timing data to find what's expensive, the failing case is exactly the one you can least afford to lose. timerx is a small, dependency-free Python timing library — a decorator, a context manager, and named stopwatches, all backed by one stats store. The one rule that shapes the whole implementation: a timing gets recorded whether or not the timed code raised. Decision 1: finally , everywhere, no exceptions to the rule @functools.wraps ( target ) def wrapper ( * args : Any , ** kwargs : Any ) -> Any : started = self . _clock () try : return target ( * args , ** kwargs ) finally : elapsed = self . _clock () - started with self . _lock : self . _record ( label , elapsed ) return wrapper The async wrapper is the identical shape with await added. The context manager ( _Lap ) does the same thing structurally, just split across __enter__ / __exit__ instead of try / finally : def __exit__ ( self , * exc_info : object ) -> bool : if self . _started is None : raise RuntimeError ( " timerx lap exited before it was entered " ) elapsed = self . _timer . _clock () - self . _started with self . _timer . _lock : self . _timer . _record ( self . _name , elapsed ) return False Note the return False — __exit__ deliberately never swallows the exception. It records the timing and lets the exception continue propagating unchanged, because a timing library has exactly one job here: observe, not intervene. A version that suppressed exceptions to "clean up" would be actively dangerous to drop into someone else's codebase. Three entry points — decorator, context manager, stopwatch — and all t

The engineering team at Zalando recently described the design and implementation of an in-process, client-side load balancer for a high-throughput API handling around 1 million requests per second. The result was more predictable latency, a drop in infrastructure costs, and better visibility into where failures actually originate. By Renato Losio

Redis gets reached for reflexively, "just add Redis," as if it were a single fix for slowness. It's genuinely one of the most useful tools in a backend engineer's kit, but using it well starts with understanding what it actually is: an in-memory data structure store, not just a cache. Once you see it as a fast, versatile store of real data structures, the range of problems it solves cleanly (caching, rate limiting, queues, sessions, leaderboards, locks) stops looking like a grab bag and starts looking like one idea applied many ways. This is the opening article of the Redis Masterclass, and it builds on the PostgreSQL series : Redis usually sits alongside a primary database like Postgres, not instead of it. In-memory is the whole point Redis keeps its data in RAM. That single fact explains most of its character. Reading from memory is orders of magnitude faster than reading from disk, so Redis operations typically complete in well under a millisecond, and a single instance handles a very high request rate. That speed is why it's the default choice for anything on the hot path, where a database round trip would be too slow. The tradeoff is that RAM is smaller and more expensive than disk, and volatile. Redis addresses durability with persistence options we'll cover later, but the mental model to start with is: Redis is fast because it's in memory, and you use it for data that benefits from being fast to access, not as the permanent home for everything. It's a data structure store, not a key-value blob The common misconception is that Redis is a simple key-value store, strings in and strings out. It's much more. Redis stores real data structures as values, each with its own commands: Strings for simple values, counters, and cached blobs. Hashes for objects with fields, like a user record. Lists for ordered sequences and simple queues. Sets for unique collections and membership checks. Sorted sets for ranked data like leaderboards and priority queues. Plus streams, bit

You've probably seen this: Kubernetes probes are green, /health returns 200, CPU isn't on fire - and users are timing out. Process is up. Just not doing anything useful. Classic event loop freeze. Something sync and expensive (or a dumb busy loop) grabs the thread, and suddenly timers, HTTP, DB callbacks - all of it waits. Including your health endpoint, because that also needs the loop. monitorEventLoopDelay() is fine for dashboards. It won't yell at you while the process is stuck, and it definitely won't write a log line from outside the frozen loop. That's the part that annoyed me enough to build this. I made @js-ak/watchdog - tiny N-API addon. The monitor runs in C++ on its own thread and writes JSON lines to stderr/file even while the JS event loop is stuck. Your freeze / recovered handlers only run after the loop unblocks. Optional RSS/CPU, optional stack sample. npm install @js-ak/watchdog const watchdog = require("@js-ak/watchdog"); watchdog.on("freeze", (e) => console.log(e.event, e.duration_ms)); watchdog.on("recovered", (e) => console.log("back after", e.duration_ms, "ms")); watchdog.start({ freezeThresholdMs: 1000, logTarget: "stderr", // or "file" | "both" source: "payments-api", }); Real freezes usually aren't while (true) . More like giant JSON.parse, a cursed regex, sync crypto/compress, or some dependency doing sync I/O on a hot path. Stuff you only notice after people complain. Prebuilds for the usual platforms (Node 22+). MIT. Repo: https://github.com/JS-AK/watchdog Curious how other people catch loop stalls in prod - and what you'd actually want in the freeze payload. Roast the API if it's wrong.

Ethereal Bytecode for the Network: Unlocking XDP's Magic! Hey there, fellow tech enthusiasts! Ever felt like the traditional networking stack in your Linux kernel was a bit… sluggish? Like it was taking the scenic route when you needed it to be a supersonic jet? Well, let me introduce you to a superhero that swoops in and turbocharges your network packet processing: eBPF, specifically in the context of XDP (eXpress Data Path). Forget the days of wrestling with complex kernel modules or praying for better hardware offload. eBPF and XDP offer a revolutionary, in-kernel, safe, and incredibly efficient way to program packet processing at the very edge of your network interface. Think of it as giving your network card a tiny, super-smart brain, capable of making lightning-fast decisions before the packet even bothers the main kernel stack. Pretty cool, right? So, buckle up as we dive deep into the wonderful world of XDP and eBPF, demystifying its power and showing you why it's becoming the darling of modern networking. 1. The "What's the Big Deal?" Section: Introduction to XDP & eBPF Imagine a bustling highway (your network). Traditional networking is like having every car stop at a toll booth, get inspected, and then directed by a central traffic controller. This works, but it can get congested. XDP, on the other hand, is like having intelligent on-ramps where some cars can be instantly identified, rerouted, or even rejected before they even hit the main highway. eBPF (extended Berkeley Packet Filter) is the technology that makes this possible. It's a powerful, sandboxed virtual machine that runs within the Linux kernel. Unlike traditional kernel modules, which can potentially crash your entire system if written incorrectly, eBPF programs are rigorously verified by the kernel for safety and correctness before they are allowed to execute. This means you get the power of kernel-level access without the existential dread of a kernel panic. XDP (eXpress Data Path) leverages

Next.js 16 shipped Cache Components - the feature that finally lets a single route mix static HTML, cached data, and per-request dynamic content without splitting it into separate pages. It is Partial Prerendering (PPR) made stable, plus a new use cache directive that replaces the old unstable_cache and the awkward route-segment config flags. This guide covers what changed, the three content types you now think in, and the runtime-data rule that trips up almost everyone on day one. What actually changed If you were using the experimental PPR flag, it is gone. Cache Components is a single config switch, and it turns on the whole model - static shell, cached segments, and streamed dynamic content in one route. // next.config.ts import type { NextConfig } from ' next ' const nextConfig : NextConfig = { cacheComponents : true , // replaces experimental.ppr } export default nextConfig Once it is on, every piece of your route falls into one of three buckets. The whole mental model is learning which bucket each component belongs in. The three content types Static - synchronous code, imports, and pure markup. Prerendered at build time and served instantly from the CDN. Your header, nav, and layout shell. Cached - async data that does not need to be fresh on every request. Marked with use cache . Think product lists, blog posts, dashboard stats. Dynamic - runtime data that must be fresh (cookies, headers, per-user state). Wrapped in Suspense so it streams in after the shell paints. import { Suspense } from ' react ' import { cookies } from ' next/headers ' import { cacheLife } from ' next/cache ' export default function DashboardPage () { return ( <> { /* Static - instant from the CDN */ } < header >< h1 > Dashboard </ h1 ></ header > { /* Cached - fast, revalidates hourly */ } < Stats /> { /* Dynamic - streams in with fresh data */ } < Suspense fallback = { < NotificationsSkeleton /> } > < Notifications /> </ Suspense > </> ) } async function Stats () { ' use cache ' cacheL

If you've ever hit deploy on AWS Fargate and watched the task sit in PENDING forever, this one's for you. I ran a small experiment with Seekable OCI (SOCI) the AWS thing that promises to fix Fargate cold starts. This article is what I learned. The good, the boring, and the "wait, that didn't work?" bits. You'll walk away knowing what SOCI is, whether you should bother setting it up, and what real numbers look like! Prerequisites ✅ You've deployed something on AWS Fargate before. You know what a Docker image is. You have an AWS account you're OK spending ~$5 on. That's it. 🤔 The Problem Fargate is great. Push a container, get a running task. No nodes to manage! Until you use a big image. Every Fargate task pulls the whole image before starting. No shared cache. No head start. If your image is 3 GB, your task waits for 3 GB to download. Every time. Every task. For an ML model or a heavy Java service, cold start becomes minutes, not seconds. Two stats made me actually care about this: 76% of container startup time is just downloading the image. Only 6.4% of that image data is needed to actually start the app. So you're pulling 100% to use 6.4%. And it costs you 76% of your startup budget doing it. That's ridiculous!! This isn't a Fargate-only problem, by the way. It's a container problem. But Fargate hurts more because you can't cache anything at the host level. I presented this talk at AWS Community Days Bangalore 2026 💡 What is SOCI? SOCI stands for Seekable OCI . Simple idea: Instead of downloading the whole image before starting the container, download only the parts the app needs right now. Everything else gets pulled lazily, in the background, while the app is already running. The way it works: You push your image to ECR like normal. A separate tool builds an index a byte-level map of what's in each layer. Fargate reads the index at startup and only fetches the bytes it actually needs to boot the process. As the app tries to read more files, Fargate fetches those

I'm training an AlphaZero-style agent (Gumbel MuZero via DeepMind's mctx ) to lay out working factory modules for Factorio: the network places machines, belts and inserters on a grid, and the reward comes from an exact throughput verifier. Everything runs in JAX on a single RTX 5070: 128 environments in one batch, an action space of A = 1729 (3 entity types × 144 cells × 4 rotations + "done"), and a small 474k-parameter conv net in bf16. While benchmarking training configurations I hit this: MCTS simulations per move training throughput XLA compile time 16 143 episodes/s 5 s 32 47 episodes/s 13 s 64 9 episodes/s 60 s Doubling the simulation budget should roughly double the cost — each simulation is one network call plus some tree bookkeeping. Instead, 16→32 costs ×3 and 32→64 costs ×5 . Something in the search was superlinear, and this post is the story of finding it in the compiled HLO and fixing it by rewriting one ~80-line function ( PR #116 ), with bitwise-identical search results. Ruling out the network First, components in isolation (batch 128): one network evaluation takes ~0.8 ms , and the rest of recurrent_fn (environment step + observation + legal-action mask) adds almost nothing on top — the whole function is also ~0.8 ms. So at 64 simulations the network accounts for roughly 50 ms per move. But a full policy step at 64 simulations costs 362 ms . Hundreds of milliseconds were going somewhere else. To localize them I benchmarked three variants of the same policy step: full — production setup; no-net — network replaced by constant logits, real environment; tree-only — no network and no environment: recurrent_fn returns the embedding unchanged. Nothing left but mctx's own tree machinery. sims full no-net tree-only 8 10.7 ms 3.7 ms 3.8 ms 16 20.9 ms 8.3 ms 8.3 ms 32 64.7 ms 34.0 ms 33.7 ms 64 362.1 ms 124.7 ms 125.0 ms The pure tree machinery is superlinear all by itself. Per simulation it costs 0.47 → 0.52 → 1.05 → 1.95 ms as the budget goes 8 → 16 → 32 → 64

Most "SSG vs SSR vs ISR" content out there is written from documentation. Someone reads the framework, restates it, and you're left inferring the actual difference in performance and behavior. So I built a lab where you can just run the commands and see it yourself, no table to trust blindly. astro-wp-seo-lab builds the same WordPress content four different ways with Astro 7.1.1, then serves all four side by side so you can compare them directly. git clone https://github.com/nimajafari/astro-wp-seo-lab npm install npm run compare That builds each arm into its own directory and serves them all at once. arm url what it is ssg-full http://localhost:4301 everything prerendered at build time ssr http://localhost:4302 rendered per request, no caching ssr-cdn http://localhost:4303 per request plus CDN cache headers route-cache http://localhost:4304 per request plus Astro 7 route caching islands http://localhost:4305 static shell with deferred fragments Every page has a black bar at the top showing which arm rendered it and when. That timestamp is the instrument for most of what follows. First build takes a few minutes since each arm fetches from WordPress, later builds are faster because the Content Layer loader caches between them. It ships pointed at a live WordPress install (oxyplug.com), but it works against any public WordPress site with the REST API exposed. npm run probe -- https://your-site.com --save mysite SOURCE = mysite npm run compare probe checks what your own install actually exposes, REST API reachability, Yoast presence, permalink structure, then saves it under a name. Use the URLs npm run compare prints for your own site instead of the ones below, since those are generated from your own content. Build time vs request time This is the distinction most of the SSG vs SSR debate hinges on, and it takes about 30 seconds to see for yourself. Open these two side by side and reload each a few times. http://localhost:4301/optimization/crl-ocsp-certificate-revocati

.The V8 engine speeds up JavaScript by dynamically compiling frequently run bytecode into optimized native machine code. However, if you pass inconsistent argument types to these optimized functions, V8 panics and deoptimizes back to bytecode. Keeping your functions monomorphic (single-typed) prevents this costly deoptimization loop, ensuring maximum runtime execution speed. If you’ve spent as much time digging into V8 execution flags as I have, you quickly realize that JavaScript is constantly rewriting itself under the hood. We like to think of JavaScript as a dynamically typed scripting language. But at runtime, engines like V8 are working tirelessly to turn your code into a highly optimized, statically typed powerhouse. When we violate that type stability, we pay a massive performance tax. How does the V8 engine optimize JavaScript at runtime? V8 uses a multi-tiered compilation pipeline that starts with an interpreter for fast startup times, then upgrades hot functions to optimized machine code using a JIT compiler. By tracking runtime type patterns, the engine can safely make assumptions to skip expensive dynamic lookups. When I look at V8’s execution pipeline, I see two primary systems working in tandem: Ignition (the interpreter) and TurboFan (the JIT compiler). Initially, Ignition compiles your raw JavaScript into bytecode so your app can boot instantly. As this bytecode executes, V8 allocates a data structure called a Feedback Vector for each function. Inside this vector are Feedback Slots (managed by Inline Caches, or ICs). These slots act as recorders, capturing the exact types (or "shapes") of the variables passing through your code. Once a function runs frequently enough to cross an execution threshold, V8 marks it as "hot" and hands it to TurboFan. TurboFan reads those feedback slots, assumes the types will remain identical in the future, and compiles a highly streamlined, native machine code version of that function. What happens when you pass differe

Modern web applications demand responsive, non-blocking user flows. This tutorial demonstrates a production-grade implementation for handling form submissions without full-page reloads using the native Fetch API and clean async/await syntax. The Complete Source Code Create a file named app.js and drop in the following event-driven architecture: JavaScript document.getElementById('registrationForm').addEventListener('submit', async (event) => { event.preventDefault(); // 1. Stop full page reload const form = event.target; const formData = new FormData(form); const submitBtn = form.querySelector('button[type="submit"]'); const responseMessage = document.getElementById('responseMessage'); // 2. UI Feedback: Disable button during network request submitBtn.disabled = true; submitBtn.textContent = 'Processing...'; responseMessage.textContent = ''; try { // 3. Asynchronous Fetch Request const response = await fetch(form.action, { method: 'POST', body: formData, headers: { 'X-Requested-With': 'XMLHttpRequest' } }); // 4. Status Code Validation if (!response.ok) { throw new Error(`HTTP error! Status: ${response.status}`); } const result = await response.json(); // 5. Dynamic UI State Handling if (result.success) { responseMessage.style.color = '#155724'; responseMessage.textContent = result.message; form.reset(); // Clear form on success } else { responseMessage.style.color = '#721c24'; responseMessage.textContent = result.error || 'Submission failed.'; } } catch (error) { // 6. Global Error Catching responseMessage.style.color = '#721c24'; responseMessage.textContent = 'A network error occurred. Please try again.'; console.error('Submission tracking error:', error); } finally { // 7. Reset UI State Guaranteed submitBtn.disabled = false; submitBtn.textContent = 'Submit Data Securely'; } }); The Problem with Synchronous Form Lifecycles Traditional submissions trigger a synchronous navigation cycle: the browser constructs a payload, issues a full HTTP request, and replaces the

Most C# developers know how to use yield return. Few understand what actually happens after compilation. If you've ever written something like this: public IEnumerable < int > GetNumbers () { yield return 1 ; yield return 2 ; yield return 3 ; } it looks almost magical. No collection. No list allocation. No iterator implementation. Yet somehow the method returns an IEnumerable. So what is really happening? The answer is one of the most elegant compiler transformations in the entire .NET ecosystem. Let's open the hood. The Illusion Most developers imagine the previous code executes like this: Call method ↓ Return 1 ↓ Pause ↓ Return 2 ↓ Pause ↓ Return 3 That isn't what happens. C# methods cannot actually pause execution. Instead, the compiler completely rewrites your method into something entirely different. The Compiler Creates a State Machine Your tiny method becomes a hidden class similar to this: private sealed class GetNumbersIterator : IEnumerable < int >, IEnumerator < int > { private int _state ; private int _current ; public bool MoveNext () { switch ( _state ) { case 0 : _current = 1 ; _state = 1 ; return true ; case 1 : _current = 2 ; _state = 2 ; return true ; case 2 : _current = 3 ; _state = - 1 ; return true ; default : return false ; } } public int Current => _current ; } Your original method no longer exists. Instead, it simply returns: return new GetNumbersIterator (); Every yield return becomes another state inside MoveNext(). Why Local Variables Don't Disappear Consider this code: IEnumerable < int > Squares () { int x = 1 ; while ( x <= 3 ) { yield return x * x ; x ++; } } After the first yield, the method "pauses." But where is x stored? Not on the stack. The original stack frame has already disappeared. Instead, the compiler promotes local variables into fields: private int _x ; The iterator object now owns every variable that must survive between iterations. This is why iterator methods can remember where they left off. Heap Allocation Happens Ma

Client-side media preflight can improve an upload experience, but it can also crash the page before the network request begins. A twelve-megapixel JPEG may be only four megabytes on disk and tens of megabytes after decoding. Creating several full-size canvases at once is enough to exhaust memory on older phones. Preflight is policy, not editing Decide what the browser must prove before transfer. Useful checks include file count, compressed byte size, declared type, readable dimensions, and a conservative duration limit for video. Avoid mandatory re-encoding unless the product truly needs it. Every transformation adds CPU time, memory pressure, battery use, and another failure mode. Process one file at a time A file picker may return twenty items. Do not decode all of them to build previews. Maintain a queue with one active decode on constrained devices and at most two on stronger ones. for ( const file of files ) { const result = await inspect ( file ); renderResult ( result ); await yieldToMainThread (); } The UI can list filenames immediately while dimensions and thumbnails arrive progressively. Prefer metadata over full pixels Use createImageBitmap with resize hints when supported. It can decode away from the main rendering path and avoid a full-resolution canvas for a small preview. const bitmap = await createImageBitmap ( file , { resizeWidth : 640 , resizeQuality : ' medium ' }); Always close bitmaps after drawing. Revoke object URLs when the component unmounts. Small leaks become large when guests select and remove files repeatedly. Handle orientation and color carefully Modern browsers generally honor EXIF orientation when decoding, but behavior differs across APIs and older engines. Test portrait photographs from real iOS and Android devices. Do not strip metadata silently if the original is supposed to remain untouched; upload the source file and treat the preview as disposable UI. Color differences between the preview and exported original are usually les

Your agent feels fast during a demo. Then a real session reaches twenty turns, several tools have returned large payloads, and every response starts taking longer and costing more. This pattern is often called token drift : the effective input context grows as an agent carries more conversation history, tool output, retrieved documents, and state into each model call. The model itself is not gradually becoming less efficient. The application is asking it to process more material on every turn. Token drift is manageable, but only if context is treated as a budgeted system resource rather than an unlimited transcript. What Token Drift Actually Means Most conversational agents build each request from several sources: a system prompt, tool definitions, recent messages, retrieved context, durable memory, and sometimes a summary of older work. Whether the application sends that state on every request or a provider manages part of it, the model still has an effective context to process. Consider an illustrative session: Turn Effective input What changed 1 1,200 tokens System prompt, tools, and one user message 8 6,900 tokens Conversation history and two tool results 20 18,400 tokens More history, retrieved documents, and accumulated state The exact price and latency depend on the model, provider, cache behavior, and workload. The important signal is the trend: later calls repeatedly process a larger context. Why Agents Accumulate Tokens So Quickly Conversation history is only one source of growth. Production agents often accumulate tokens in several places at once: Repeated transcripts: Every prior user and assistant message remains in context. Tool schemas: Large tool descriptions and JSON schemas may be attached to every model call. Tool results: Search results, stack traces, database rows, and API responses can be much larger than the user's request. Retrieved documents: RAG pipelines sometimes add too many chunks or keep stale retrieval results across turns. Retries an

Ruth Linehan explains how migrating high-performance caching services from Kotlin to Rust shattered internal preconceptions around delivery velocity and engineering overhead. She discusses the ergonomics of the Rust borrow checker, shares how compile-time safety shortens the developer feedback loop, and profiles how tools like Criterion and flamegraphs optimize concurrent code paths. By Ruth Linehan

I made ClickHouse and Postgres Fight to Find Out 🥊 One Mac Mini. Two databases. 100 million rows of...