/Performance

Cloud Exit Pays Off In Performance Too

- David Heinemeier Hansson tl;dr: “Each of these machines were less than $20,000. Amortize that over five years. That's $333/month for all the hardware (minus routers etc) needed to run Basecamp Classic today. And this is still a large SaaS app that's generating literally millions of dollars in revenue per year.”

featured in #411


You Don’t Have To Sacrifice Streaming Data Performance To Cut Cloud Costs

tl;dr: Redpanda is faster and more efficient than Apache Kafka… but how much faster exactly? We ran 200+ hours of benchmarks to find out how both platforms perform for various workloads and hardware configurations. Here’s our breakdown on how Redpanda achieves 10x the performance while cutting cloud spend by over $500k.

featured in #407


You Don’t Have To Sacrifice Streaming Data Performance To Cut Cloud Costs

tl;dr: Redpanda is faster and more efficient than Apache Kafka… but how much faster exactly? We ran 200+ hours of benchmarks to find out how both platforms perform for various workloads and hardware configurations. Here’s our breakdown on how Redpanda achieves 10x the performance while cutting cloud spend by over $500k.

featured in #405


The World's Smallest Hash Table

- Orson Peters tl;dr: Orson tackles an Advent of Code, which he optimizes “completely beyond the point of reason” but also contains a useful technique, showing us how to store a small lookup table with small elements as a constant, indexed using shifts.

featured in #395


Rust Coreutils: Fixing Low-Hanging Performance Fruit

- Patrick Jackson tl;dr: “A few months ago I took a look at the [uutils coreutils](https://github.com/uutils/coreutils) project, which is a rewrite of the core GNU utils in Rust, to try to get some experience writing newbie code in the language. I saw the maintainers themselves mention that a lot of the code quality isn’t great since a lot of contributions are from people who are very new to Rust, so I figured there would be some easy fixes available for me to take on.”

featured in #393


How We Improved DNS Record Build Speed By More Than 4,000x

- Alex Fattouche tl;dr: "Our network now spans over 270 cities in over 100 countries, interconnecting with more than 10,000 networks globally. According to w3 stats, “Cloudflare is used as a DNS server provider by 15.3% of all the websites.” This means we have an enormous responsibility to serve DNS in the fastest and most reliable way possible."

featured in #383


In-Depth: ClickHouse vs PostgreSQL

- Mathew Pregasen tl;dr: "Most companies that invest in an online analytical processing (OLAP) database like ClickHouse originally used an online transaction processing (OLTP) stack like MySQL or Postgres." Despite the two being built for different purposes, most companies leverage features in both during their scaling period. The author compares the two technologies here. 

featured in #372


I/O Is No Longer The Bottleneck

- Ben Hoyt tl;dr: "When interviewing programmers, I often ask them to code a simple program to count word frequencies in a text file. It’s a good problem that tests a bunch of skills, and with some follow-up questions, allows you to go surprisingly deep. One of the follow-up questions I ask is, “What’s the performance bottleneck in your program?” Most people say something like “reading from the input file”." Ben discusses why that's not usually the case.

featured in #370


Making A Go Program 42% Faster With A One Character Change

- Harry Marr tl;dr: "If you read the title and thought “well, you were probably just doing something silly beforehand”, you’re right! But what is programming if not an exercise in making silly mistakes? Tracking down silly mistakes is where all the fun is to be had! I’ll also state the usual benchmarking caveat up front: the 42% speedup was measured while running the program on my data on my computer, so take that number with a big old pinch of salt."

featured in #369


Seeing Through Hardware Counters: A Journey To Threefold Performance Increase

- Vadim Filanovsky Harshad Sane tl;dr: "There is, however, a class of problems that requires an even stronger level of magnification going deeper down the stack to introspect CPU microarchitecture. In this blogpost we describe one such problem and the tools we used to solve it."

featured in #368