Loading…
Topic
817 posts about Performance. Every summary links to the original.
See the idea
Bare metal gives engineers direct control over GPU, network, and virtualization layers, but it shifts elasticity and lifecycle work onto the team. This trade-off map shows when that bargain pays off.
Bun packs a runtime, package manager, bundler, and test runner into one binary. Here is how those four parts fit together and where the seams still show.
A five-step how-to for deciding when an AMD Instinct GPU should stay dedicated and when SR-IOV virtual functions, VMs, or sidecar isolation can safely share it.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Shopify reviews five years of using React Native (RN) as its mobile strategy, adopted to avoid duplicating features across iOS and Android, improve talent portability, and ship more value. Over that period, all of its apps migrated to RN through team-led, non-uniform plans, while native code remained part of the architecture rather than an alternative to eliminate. The company reports sub-500ms P75 screen loads in the Shopify app, similar performance across its apps, and more than 99.9% crash-free sessions, while noting that performance depends on applying sound patterns. Its experience credits hot reloading and TypeScript with developer productivity and cross-platform staffing, but identifies debugging, RN upgrades, and third-party dependency maintenance as costs. Shopify now emphasizes shared libraries, native expertise for platform-specific work, continued New Architecture adoption, and collaboration with the RN ecosystem.
Canva's global print network requires selecting optimal suppliers to balance delivery times, packaging counts, and environmental emissions. To resolve these challenges before user checkout, the engineering team designed a modular routing architecture that decouples graph construction, decision logic, and path traversal. During graph traversal, the system generates action objects capturing forward paths and decision query results, which are compiled into timestamped routing logs in blob storage for asynchronous auditing. Utilizing preprocessed graph queries alongside ElastiCache, Redis, and database read replicas, the infrastructure sustains high-throughput evaluation without coupling cost logic to traversal code. As a result, print routing completes within an average of 50 milliseconds at the 99th percentile during peak usage while maintaining 99.999% data availability.
The article examines how applications should store and access product data in simple Stripe integrations as requirements for security, performance, and scalability evolve. It compares using Stripe’s built-in product fields with a separate database, while explaining that publishable API keys cannot retrieve product details and that secret or restricted keys must remain server-side. A web backend or serverless function can proxy requests securely, while CloudFront caching reduces repeated calls and latency but requires an appropriate refresh cadence. For richer metadata, inventory, variants, or custom attributes, the article describes combining DynamoDB with Lambda and Stripe, using Event Destinations or webhooks to synchronize changes and weighing that flexibility against database overhead.
GrabX, Grab’s central product configuration management platform, provides an SDK whose eventually consistent updates take about a minute to reach clients, but initialisation took roughly four minutes for services loading around 400 MB. The SDK’s sequential workflow downloaded subscribed-service and common data from AWS S3 to disk and memory before initialising dependent modules, creating cold-start pressure and possible throttling when new instances were launched. Phase 1 made the two data loads concurrent, reducing initialisation time by approximately 80%, while Phase 2 concurrently downloaded and loaded large configurations within a subscribed service, adding a further approximate 6% reduction. Phase 3 removed disk persistence because its stale-data fallback conflicted with most clients’ need for current data, allowing failed connections to trigger client action such as retrying. Benchmarks across services with varied data sizes indicated reductions of up to 90%.
Heroku’s Router 2.0 beta exposed elevated tail response times and request failures in a subset of Puma applications, especially under 200 milliseconds of server-side lag and 30 requests per second. Investigation compared legacy and Router 2.0 connections, examined TIME_WAIT behavior, and tested Go’s http.Transport idle-connection limit; raising MaxIdleConnsPerHost from the default of 2 to 100 stabilized connection states but did not improve latency. The underlying issue was Puma’s handling of persistent connections, where request balancing could leave work queued behind busy connections; disabling keepalives eliminated the problem, while thread, worker, and max_fast_inline tuning were offered as alternatives. Load tests found the issue unique to Puma, and the update reports that Puma 7.0 fixed the bug, recommending version 7.0.4 or higher.
Heroku Router 2.0 is generally available and is expected to become the default, making migration planning important before rollout. The guidance recommends creating a staging application, enabling the http-routing-2-dot-0 feature, restarting web dynos when needed, and checking response headers and system logs to confirm routing. Router 2.0 identifies requests with Via values such as “2.0 heroku-router” or “1.1 heroku-router,” and its logs add protocol, tls, and tls_version fields. HTTP/2 is enabled by default on custom domains with valid TLS certificates, while HTTP/2 can be disabled through a Labs feature. Keepalives are also enabled between the router and web dynos, but applications using recent Puma versions may need the keepalive opt-out because of a connection-handling bug.
GrabX’s product configuration SDK used substantial memory and CPU because every client downloaded, decoded, and loaded a single JSON file containing configurations for all services, even when it needed only a small subset. The design also regenerated and fetched complete files every minute, while decoding a file larger than 100 MB could starve request handling and increase P99 latency. The proposed redesign partitions data by service, stores each configuration in its own JSON file and S3 prefix, and adds service-level changelogs so SDKs subscribe only to required services and apply targeted updates. Benchmarking across varied configuration sizes found potential reductions of up to 70% in memory utilisation and more than 50% in maximum CPU utilisation. Further work is planned to reduce SDK initialisation time.
The 2023 BFCM Globe is a real-time visualization of purchases made through Shopify-powered merchants worldwide, with animated arcs, city dots, fireworks, camera movement, atmospheric noise, stars, and a custom material. Performance was a central concern because the earlier approach used a separate mesh and draw call for every arc, causing more than 1,000 simultaneous arcs to slow some mobile devices. The revised arc system uses instancing, interleaved per-arc attributes, and vertex-shader Bézier deformation, allowing tens of thousands of arcs in one draw call and an initial benchmark of up to one million arcs on an M1 laptop. Other effects were similarly consolidated, including billboarded point particles for cities and single-draw-call fireworks, while 2D psrdnoise and a stripped-down shader reduced rendering cost. The result combines richer visuals with substantially greater rendering capacity.
Payment method choices affect ecommerce conversion, and the post notes that 81% of surveyed customers frequently abandon carts when their preferred method is unavailable. It explains how Stripe’s dynamic payment methods in Elements and Dashboard settings can apply country, region, and amount rules without embedding those conditions in PaymentIntent code. The proposed workflow uses Dashboard experiments to enable methods such as Klarna, set display rules and traffic allocation, then uses Workbench Inspector, Logs, and Events tabs to inspect presented payment_method_types, API requests, and webhook history. A Klarna example reports a 16% increase in average order value, while new payment methods were deployed within four days.
Shopify describes how it built near-real-time text and image embedding pipelines to support semantic search, replacing keyword matching with representations that enable similarity-based retrieval. Using Google Cloud’s Dataflow and Apache Beam, the pipelines process roughly 2,500 embeddings per second, preprocess images, run GPU-backed inference, and write outputs to both a data warehouse and an event topic for downstream ingestion. The engineering discussion focuses on trade-offs among memory, throughput, latency, and cost: reducing harness threads cut memory use about 2.6x and allowed a return to cheaper workers, while model sharing reduced throughput. For batching, bursty input produced bundles of one, and stateful batching was rejected because its shuffle increased latency; Dataflow’s per-process model instances instead provided enough parallelism to saturate GPUs.
Two Sigma's large computing footprint drives significant energy consumption and carbon emissions, particularly across live trading applications that require continuous real-time market data caching. To address this overhead without sacrificing performance, engineering teams used a routine hardware refresh to transition from legacy single-process machines to denser multi-core server configurations. By replacing roughly 60 legacy hosts with 28-core processor hardware, the team distributed baseline power draw over more cores and eliminated underutilized compute capacity. This architectural consolidation reduced absolute power consumption across production hosts by 66%, dropping electricity usage from 27 MWh in January 2023 to 10 MWh in January 2024. The initiative subsequently established an annual sustainability rationalization practice for hardware budgeting across the organization.
MongoDB 8.0, the latest version of the document database, is now generally available, delivering significant performance and security improvements. The release features 36% better read throughput, 56% faster bulk writes, 20% faster concurrent writes during data replication, and 200% faster complex aggregations of time series data. MongoDB’s internal build system, which runs on MongoDB, saw query latencies drop by approximately 75% after upgrading. The company also reports that customer OCELL experienced queries running twice as fast. MongoDB 8.0 includes sharding enhancements for up to 50 times faster data distribution, quantized vectors that reduce memory usage by up to 96%, and expanded Queryable Encryption to support range queries. The release is available via MongoDB Atlas, MongoDB Enterprise Advanced, and MongoDB Community Edition.
The post presents advanced error-handling patterns for Stripe integrations that face high request volumes, temporary API slowdowns, connectivity problems, and webhook delivery failures. It uses Stripe Workbench to inspect account-level API activity, traffic spikes, error rates, API versions, and webhook activity; one example links a 429 response to a scheduled job that created usage records across thousands of accounts simultaneously. The implementation combines request spacing with Limiter, a p-queue concurrency cap of five, and a token bucket configured for 100 tokens per 60 seconds. Stripe’s stated limits are 100 read and 100 write operations per second in live mode and 25 of each in test mode, with stricter limits for some resources. The reported before-and-after results show the combined controls processing high API-call volume within those limits, reducing errors and producing more predictable interaction.
MySQL requires locks before updating existing records, and concurrent upserts that mix new and existing rows can deadlock when gap locks overlap, even when processes target different records. The post describes ETL jobs partitioned by account whose updates nevertheless contend because sequential primary-key ordering places records in shared index gaps. It proposes replacing the existing primary key with a composite key of account and id, aligning InnoDB's physical row ordering with the processes' update partitions; gap locks remain necessary, but are largely compartmentalized within each process. An additional unique index on id preserves standalone record identification and compatibility with existing joins, while application and ETL logic remain unchanged. The reported outcome was removal of artificial delays and significantly higher import throughput through reduced job wait time.
Shopify’s checkout is a managed service requiring control over scripts to support high-performance, PCIv4 DSS-compliant checkout and prevent tampering. SRI could validate top-level resources but did not cover imported JavaScript modules, forcing a shim for dynamic imports that added maintenance and runtime overhead. The work revived Guy Bedford’s proposal to put integrity hashes in import maps, enabling unchanged dynamic imports while also covering static imports, top-level module scripts, and modulepreload. Support shipped in Chromium 127 for Chrome and Edge, and landed in Safari 18’s beta release, with just over two weeks of full-time work and about seven chronological weeks overall.
Profile-guided optimisation (PGO) improves Go application performance by feeding production CPU profile data into subsequent compiler builds. Teams evaluated PGO across multiple Grab services, including TalariaDB and an orchestrator within the Catwalk service, using Go 1.20 and Go 1.21 builds. TalariaDB saw substantial resource savings after compiling Docker images with a 360-second pprof profile, resulting in at least a 10% drop in CPU usage, a 30% drop in memory consumption, and a 38% reduction in persistent volume usage for event ingestion queues. Conversely, testing on Catwalk showed only a 5% performance gain after adjusting the profiling duration from 59 seconds to 6 minutes, an outcome deemed insufficient to justify pipeline modifications. Broader adoption across monorepo services remains constrained until the central build process supports PGO arguments and automated profile retrieval.
Large code edits expose coding agents to laziness, inaccuracy, and latency, especially when frontier models must rewrite hundreds of lines. The post presents fast apply, a specialized full-file code-edit model that separates planning from applying: Cursor's frontier model plans the change, while the apply model rewrites the current file. It evaluates roughly 450 edits on files under 400 lines, using Claude-3 Opus as grader, and finds llama-3-70b-ft nearly matches claude-3-opus-diff while outperforming GPT-4-Turbo and GPT-4o. Rather than generate conventional diffs, it uses full-file rewrites and search/replace hunks, which avoid line-number errors and give models more output tokens for reasoning. A custom speculative decoding method, deployed with Fireworks, reaches approximately 1,000 tokens per second on a 70b model, about 13x faster than vanilla Llama-3-70b inference and 9x faster than the previous GPT-4 deployment.
Standard infrastructure monitoring tools track CPU and memory usage at the host or container level, obscuring the precise resource consumption of individual Spark jobs on shared instances. To achieve granular observability, the Iris platform gathers job metrics directly at the Java Virtual Machine level without requiring changes to user application code. Data collection relies on Uber's JVM Profiler for deep JVM, thread, and memory pool diagnostics alongside sparkMeasure for stage and task execution statistics. Collected metrics route asynchronously through an Apache Kafka queue to avoid execution bottlenecks, feeding a Telegraf, InfluxDB, and Grafana stack for real-time monitoring while archiving to a data lake for offline analytics. This multi-tiered telemetry enables engineering teams to identify over- or under-provisioned jobs and optimize ETL resource allocations.
Researchers reviewed prominent machine learning papers presented at NeurIPS 2023 covering large language models and statistical learning theory. One investigation showed that claimed emergent abilities in models such as GPT-3 often result from nonlinear evaluation metrics rather than fundamental shifts in model capability. To reduce the computational burden of model adaptation, QLoRA enables 65-billion-parameter model fine-tuning on a single 48-gigabyte GPU via 4-bit NormalFloat quantization and paged optimization. Direct Preference Optimization eliminates complex reward modeling by casting reinforcement learning from human feedback into a preference classification task. Additional work resolved statistical anomalies like double descent using effective parameter counts and introduced stochastic gradient approximations for Gaussian processes.
Shopify’s mobile app saw performance decline during its React Native migration, prompting a year-long effort to make critical screens load under 500ms at P75 and launch within 2s at P75. The team built real-time dashboards to filter results by device and operating system, then targeted excessive initial rendering, unnecessary background updates, launch overhead, and weak cache utilization. They introduced LazyScrollView and ListSource on FlashList, deferred work outside the viewport, enabled inlineRequires, optimized a native module, batched state updates, froze background components, and improved Restyle. They also fixed a graph QL cache issue and pre-warmed critical screen data, increasing cache-first delivery to as much as 90% for key screens. By year-end, app launch P75 was 44% faster and screen-load P75 times were reduced by 59%, with performance treated as an ongoing process requiring monitoring and repeated optimization.
The best engineering reads, once a week.
