I optimized four Speed Demon tracks. The scoring box changed my mind.

Peeter Tsanev — Tue, 03 Nov 2026 21:21:12 +0000

I entered Speed Demon 2026, a 72-hour performance contest organized by Hackathon Raptors, with solutions for all four tracks. The code froze on November 2, 2026. I kept the final implementation and the experiment logs in my public repository.

I expected the fastest local version to be the strongest submission. That expectation failed twice in the final round. I also learned that a memory saving can beat a speed improvement, that a shorter source file can score as longer code, and that passing a SHA-256 output check does not prove an internal hash table is collision-safe.

This is the account of the measurements, including the changes I reverted.

The score is not just elapsed time

The contest assigned each track a multiplicative performance factor:

K = (Tref / T)^0.5 × (Mref / M)^0.2 × (Sref / S)^0.15 × (Dref / D)^0.15

T is wall-clock time. M is peak charged memory. S is counted code lines. D is one plus the number of direct runtime dependencies. The corresponding reference measurements have the ref suffix. Memory benefit was capped at a 50-fold ratio, and the code-size factor could not exceed 1. For the four C++ entries, D was 1.

Machine points were 50 × log10(K), capped between 0 and 100. Machine results accounted for 65% of a track total, with 35% assigned to judging. I treated the machine score as the part I could measure directly, without claiming it predicted the judges' points.

The exponents matter. If everything else is fixed, halving time raises K by 2^0.5 = 1.414. Halving memory raises K by 2^0.2 = 1.149, or about 15%. The latter is a meaningful gain even when the program does not get faster.

Here are the four scores on the frozen commit, as reported by the public board on November 2. These are single scoring-box runs, not local estimates.

Track	Time	Peak memory	Counted lines	K	Machine points
A, request aggregation	0.03974 s	30.94 MB	298	32.95	75.89
B, text indexing	0.35296 s	59.17 MB	1,044	18.06	62.84
C, distinct-name aggregation	0.07365 s	16.50 MB	443	21.08	66.19
D, graph paths	0.55867 s	83.41 MB	523	12.60	55.02

The scoring machine used an Intel i5-13500 with 12 hardware threads and turbo disabled. My test laptop (i5-1035G1, 8 threads) used the same full-size dataset and correctness outputs, but not the same CPU or scheduling environment. That distinction became central.

Memory was a scoring axis I could calculate

The organizers published reference times of 32.05, 56.35, 14.44 and 72.69 seconds for A through D. The public board exposed each of my runs' T, M, S, D and K. By rearranging the formula, I could back-solve the reference memory used in the score:

Mref = M × [K / ((Tref/T)^0.5 × (Sref/S)^0.15 × (Dref/D)^0.15)]^5

Using the frozen runs and the published reference line counts of 56, 91, 108 and 43, I obtained approximately 228 MB for A, 2,200 MB for B, 368 MB for C and 893 MB for D. These are reconstructed numbers, not independent reference-process measurements. They reproduce the board's reported K after rounding.

That calculation changed where I spent effort. For B, reducing peak memory from roughly 99 MB to 59 MB could matter even when an algorithmic rewrite saved only hundredths of a second. Round 6's chunked 16-bit postings lowered the test laptop's measured peak from 94,824 KB to 60,712 KB; its estimated K rose from 13.4 to 14.9. I retained that storage approach before trying the final phrase rewrite.

There was another accounting detail: the output file counted toward memory.peak. On A, the full output was about 10.1 MB. A separate 10 MB write to the temporary output filesystem increased measured peak by about 12.3 MB. Optimizing the parser alone could not make the charged peak vanish. The input dataset was prewarmed and its /data page cache excluded; output pages were not.

The line count punished clever formatting

The code-size factor was not a count of what I typed. The scoring pipeline first ran clang-format --style=LLVM and then scc 4.1.0 on code files and the Dockerfile. Documentation and configuration metadata did not count. The metric was the code-line count after formatting, so compressing many statements onto one long line did not buy a smaller S.

In an early B experiment, 353 written lines became about 970 counted lines. That difference made some compact-looking rewrites disappointing. In D's last round, a hash-deduplicated query variant took 0.893 seconds on the test laptop versus 0.897 for the retained version, but required 572 counted lines instead of 562. Both rounded to K 10.0. I retained the smaller source rather than treating a four-millisecond advantage as a win.

A also illustrates the trade-off. The move from the round-four design to packed four-byte records and 512-record blocks grew the counted source from 283 to 298 lines. But memory fell from 36.7 MB to 29.9 MB, and the board's K went from 31.9 to 33.4. The larger program scored better.

My test laptop selected the wrong final experiments

On my test laptop (i5-1035G1, 8 threads), C's round-seven owner-queue design raised the estimated K from 17.7 to 20.4. It routed name updates into eight single-owner queues to avoid atomics on country masks. The idea was reasonable, and its memory saving appeared real.

The official 12-thread scoring machine disagreed. Relative to C's retained round-six run at 0.07303 seconds and 16.55 MB, round seven used about 38% less memory but took about 0.0873 seconds, roughly 20% longer. Its K was 20.85 instead of 21.16. I reverted it. The local result had predicted memory and line count better than it predicted time.

Track B produced a different warning. Round seven moved exact phrase verification into the document scan, eliminating a separate positional index. My local check built with fixed compiler flags. I then submitted a version with -funroll-loops enabled.

On the board, the flagged version took 0.445845 seconds with K 16.11. Removing that flag from otherwise matching source gave 0.354023 seconds with K 18.05. The flag cost about 26% in elapsed time in those samples, despite almost identical memory and the same 1,044 counted lines. This is a one-run comparison, not proof that the flag is always bad. It was sufficient evidence not to retain it for this entry.

The hash trap that passed the output checks

C required grouping names exactly while aggregating country masks. Storing each entire name made the interner larger, so I experimented with hash-only fingerprints. The collision question was not academic: a collision between two distinct names would silently merge their aggregates.

One rejected design used two CRC32C streams with different seeds as a supposed 64-bit fingerprint. That sounds like 64 bits of independent evidence. But CRC operations are linear or affine over their input, so changing only the initial seed can leave the two results related by a fixed affine transformation. Two dependent 32-bit streams do not automatically make a strong independent 64-bit fingerprint.

The design passed the expected-output SHA-256 checks on the routine datasets. My experiment log records that a broader audit of about 2 million names over 20 seeds nevertheless found three collisions between distinct names, two in seed 5 and one in seed 18. I kept the log line, not the raw trace, so treat the exact count as logged rather than reproducible. A correct output checksum on a few inputs does not establish that the internals are collision-free for another input.

I changed the experimental second stream to mix its result with odd multipliers, breaking that simple seed-only relationship. A separate 50-seed audit covered 5,000,050 names and found zero full 64-bit collisions. Zero observed collisions is still not a proof. I ultimately reverted the round-seven owner-queue version for its board performance and kept the round-six interner. The correctness risk and the speed result were separate decisions.

What failed was as useful as what stayed

These are three examples from the experiment logs. The times in this table come from the test laptop, not the scoring board.

Track	Experiment	Measured result	Decision
A	Reduce record blocks from 512 to 256	Median 0.060 to 0.067 s; peak 28,020 to 29,476 KB	Revert
B	Evaluate Boolean and phrase queries directly during scanning	Median 5.186 s versus a roughly 0.7 s indexed design; 209,094,387 Boolean candidate checks	Revert
D	Parallelize CSR scatter with dense degree arrays	Median 1.207 to 1.456 s, about 21% slower	Revert

The B failure was particularly informative. Eliminating the intermediate index reduced memory, but 209 million candidate Boolean evaluations overwhelmed that saving. A phrase-only version remained useful as a separate direction; evaluating all query types inside the scan was the mistake.

For D, packing the search heap and staging CSR cursors reduced memory without requiring a more complicated parallel scatter. The retained round-six design measured 0.897 seconds and 80,632 KB on the test laptop, at K 10.0. The frozen scoring-box version later ran in 0.55867 seconds with K 12.60. I do not mix those two timings into one speedup calculation.

Even the board was noisy

I reran identical A source on the official box. One run took 0.03924 seconds, another 0.04270 seconds, about 9% slower with no algorithm change. A third repeat logged roughly 0.0387 seconds. The memory peak moved as well. The K difference between the first two was 33.4 versus 31.8.

That is large enough to blur several optimizations I had considered successes on one run. I started using the median of five local runs to screen changes, byte-for-byte checks on sample and full datasets, and independent generated seeds to catch correctness mistakes. None of those steps makes local timings interchangeable with board timings. They do make it harder to mistake a single fast measurement for an improvement.

The frozen entry was commit bf0866a, with all four tracks passing the board's build, correctness, timeout and sandbox gates. I did not end with the best previously observed A or C score on every rerun. I ended with the source whose behavior and trade-offs I could explain.

For this 72-hour contest, the useful conclusion was narrower than "make everything faster." I had to optimize the measured formula, count output memory, measure the formatted source, distrust correlated fingerprints, and verify speed on the actual 12-thread scoring machine. The failed runs provided most of those lessons.

Disclosure: Claude, an AI model, did the engineering for this entry and wrote this post for the account owner, and ChatGPT-based workers ran part of the experiments. The contest rules expect AI tools. Every number here comes from the public board or from the run logs in the repository.

DEV Community: Peeter Tsanev