Tema: performance
-
Perfilado continuo en producción: perfiles de muestreo siempre activos y qué preguntas responden
El perfilado continuo toma perfiles de CPU y memoria de manera sistemática a lo largo del tiempo y los almacena como series etiquetadas, de modo que un equipo puede preguntar qué función consumió más CPU en toda la flota ayer, o qué cambió entre dos versiones; los perfiladores por muestreo lo abaratan lo suficiente como para dejarlo siempre activo, y endpoints en tiempo de ejecución como /debug/pprof/ de Go, o agentes eBPF, son quienes suministran los perfiles.
-
Medir el rendimiento de un cambio (benchmarking): calentamiento, repeticiones, varianza y qué informar
Una comparación de tiempos solo es un resultado si sobrevive al ruido: fija la carga de trabajo, descarta las ejecuciones de calentamiento, intercala muchas repeticiones de cada variante, elige el estadístico antes de mirar los datos, e informa la dispersión y el entorno junto a cada cifra. Una diferencia menor que la dispersión entre ejecuciones no es un hallazgo.
-
The USE method for finding performance bottlenecks
For every resource (CPU, memory, disks, network, locks), check utilisation, saturation and errors; the USE method is a checklist that finds bottlenecks quickly without guessing at the application layer first.
-
Response compression: where to do it and what to exclude
Compress text responses (HTML, JSON, Markdown) at the proxy or the application, skip already-compressed and streaming content, keep ETags honest across encodings, and set Vary: Accept-Encoding.
-
How much of an agent's context is tool output in real runs, and does trimming it change task success?
Open question: the MCP specification says clients should validate tool results before passing them to the model but leaves the amount to the client; in recorded agent runs, what share of tokens is tool output rather than instructions or reasoning, and does truncating, summarising or filtering tool output change task success, cost and latency?
-
Responsive images with srcset, sizes and picture
srcset with width descriptors plus a sizes attribute lets the browser pick the smallest image file that fills the slot at the current viewport and pixel density; x descriptors serve fixed-size images at several densities; picture with source elements handles art direction and format fallback. Always keep width and height so the layout does not shift while the image loads.
-
Generate, critique, revise: when a self-verification loop pays for itself
A loop in which the model critiques and revises its own output improves results when the critique has an external signal (tests, a validator, a source) and a fixed rubric; without one, published results show it can degrade answers, and each round adds at least two calls whose input grows with the draft.
-
VACUUM, autovacuum and table bloat
PostgreSQL's MVCC leaves dead row versions behind after updates and deletes; VACUUM reclaims them and maintains statistics and transaction-id wraparound protection. Autovacuum should stay on and be tuned for busy tables.
-
Web font loading: font-display, preload, unicode-range subsetting and metric-matched fallbacks
Show text on first paint and load the brand font without layout jumps: subset faces with unicode-range so only used scripts download, choose font-display per role (optional for body text, swap for headings), preload the first-paint files with crossorigin, and declare a fallback face with size-adjust and ascent/descent overrides so lines wrap the same before and after the swap.
-
ES module builds with declared side effects shrink consumer bundles more than CommonJS builds
Hypothesis: for a library of many independent functions, a consumer that imports a few of them gets a smaller bundle when the library ships ES modules with a sideEffects declaration than when it ships CommonJS, because tree shaking depends on static import/export structure; a fixture-based comparison is proposed.
-
When asyncio helps and when it does not
asyncio runs many I/O-bound tasks on one thread by suspending at await points; it does not speed up CPU-bound code, and blocking calls inside coroutines stall the whole loop.
-
Web Vitals: what LCP, INP and CLS measure
Core Web Vitals are three field metrics: Largest Contentful Paint (render time of the largest visible element, target 2.5 s), Interaction to Next Paint (longest interaction latency, target 200 ms) and Cumulative Layout Shift (unexpected movement, target 0.1), each assessed at the 75th percentile of page loads.
-
When does client-side routing still pay off now that browsers offer bfcache, prerendering and cross-document view transitions?
Open question: in-page routers were adopted to avoid full page loads, at the cost of shell serving, 404 handling, scroll and focus restoration and a bundle that must arrive first; the back/forward cache, the Speculation Rules API and cross-document view transitions now address the original motivations in multi-page sites. For which sites and interaction patterns does an in-page router still measurably win?
-
Finding a memory leak with tracemalloc snapshots
Start tracing early with PYTHONTRACEMALLOC or tracemalloc.start(nframe), take a snapshot after warm-up and another after N iterations, filter import noise, and read compare_to(..., 'lineno') for lines whose size grows proportionally to N; switch to 'traceback' grouping to see the callers.
-
Choosing between threads, processes and asyncio for a Python workload
Classify the hot path first: waiting on I/O suits asyncio (many connections, async libraries) or a thread pool (few blocking calls); pure-Python CPU work needs processes or a free-threaded build; native code that releases the GIL can use threads. Bound every pool, choose the process start method explicitly and write the shutdown path.
-
Reading a flame graph: width is samples, the x-axis is not time
A flame graph stacks sampled call stacks so that frame width is the share of samples and height is stack depth; the x-axis is sorted alphabetically, not by time. Read wide plateaus at the top as on-CPU hot spots, wide frames with many thin children as callers to call less often, and remember that a CPU flame graph cannot show waiting.
-
SVG icons: inline markup, a sprite with use, or an img element
Inline SVG can be styled with currentColor and CSS but repeats bytes on every occurrence; a same-origin sprite referenced with use is cached once and still follows the text colour; an img is cacheable but opaque to CSS. Pick per icon role, keep decorative icons hidden from assistive technology, and size every icon so nothing shifts while the sprite loads.
-
Database connection pooling and its limits
Each PostgreSQL connection is a process with memory cost; applications should keep a small pool sized to real concurrency, set acquisition timeouts, and never let request handlers open ad hoc connections.
-
Load testing with open and closed workload models
In a closed model a fixed number of virtual users wait for each response before sending the next request, so a slowing server throttles its own load and the worst periods go unmeasured; in an open model requests arrive at a set rate regardless of completion. Choose the model from the question being asked and report it with every number.
-
Planner statistics in PostgreSQL: statistics targets, correlated columns and misestimates
The planner estimates row counts from per-column statistics that ANALYZE samples (most common values, histograms, distinct counts) and assumes independent columns; misestimates come from stale statistics, skewed columns with too few entries, correlated columns and expressions. Raise the statistics target on specific columns, create extended statistics for correlated columns or expressions, re-analyze, and compare estimated with actual rows.
Legible por máquina: JSON