Shlemiel the Painter Is Back: How Zig’s libc Rewrite Made SQLite Slower

In 2001, Joel Spolsky penned an influential article titled "Back to Basics," highlighting the importance of understanding fundamental algorithms in computing. One example he provided was the "Shlemiel the Painter" trap, where a seemingly simple choice can lead to quadratic runtime complexity. This concept resurfaced in 2026, when a chess analysis service built on Rust and SQLite exhibited unexpectedly slow performance.

The service primarily functioned as a Rust service backed by SQLite, processing hundreds of chess games and outputting large JSON bundles. While the analysis tasks consumed a significant number of cores on the runner, the process of storing the data should have taken only milliseconds. However, inserting JSON data into the SQLite database took minutes, causing the service to become CPU-bound.

This issue was traced back to Zig's cc compiler and its replacement for standard library functions, which were used to compile SQLite for cross-platform building.

Within the rewrites of string manipulation functions, such as strspn, strcspn, strpbrk, and strstr, the first step measured the entire length of the string. This introduced a Shlemiel the Painter pattern, causing the tokenizer to repeatedly remeasure the string length while processing a 1.2MB file. As the file size increased, the slowdown became quadratic, leading to a significant performance degradation.

Although the author expressed no ill will towards the developers involved, he emphasized the need to remain vigilant for similar issues in the future. He discovered that pre-pruning whitespace from JSON greatly reduced the cost of tokenizing in SQLite, but he needed to address the underlying problem to prevent further performance issues. This story serves as a cautionary tale, reminding developers to be aware of potential pitfalls in seemingly minor code changes.