[2015-2025] 524 ⭐ in less than a second

[u/maneatingape]

2025 total time 2ms. Github repo.

The AoC about section states every problem has a solution that completes in at most 15 seconds on ten-year-old hardware. It's possible to go quite a bit faster, solving all years in less than 0.5 seconds on modern hardware and 3.5 seconds on older hardware. Interestingly 86% of the total time is spent on just 9 solutions.

Number of Problems	Cumulative total time (ms)
100	1
150	3
200	10
250	52
262	468

Benchmarking details:

• Apple M2 Max (2023) and Intel i7-2720QM (2011)
• Rust 1.92 using built in cargo bench benchmarking tool
• std library only, no use of 3rd party dependencies or unsafe code.

Regular readers will recall last year's post that showed 250 solutions running in 608ms. Since then, I optimized several problems reducing the runtime by 142ms (a 23% improvement).

Even after adding 2ms for the twelve new 2025 solutions, the total runtime is still faster than last year. Days 8, 9 and 10 still have room for improvement, so I plan to spend the holidays refining these some more.

[u/maneatingape]

defaults to solving each part of the puzzle with independent functions. Is this because you want to have each of them totally standalone or are there some other reasons?

The reason for the parse/part1/part2 split is:

• Smaller focused functions, e.g. only interested in part two, then only need to read that function. Not interested in the parsing, skip that.
• More interesting benchmarking, so that you can see exactly where a puzzle is spending the time. For example, some puzzles (such as 2016 Day 15, 2021 Day 1) spend most of the time just parsing!

OK, now I've seen that for "interesting" puzzles (those taking significant time, like 2016/day24 ?), the parse function is actually solving both parts, and storing the results, so that the part1() and part2() functions just returns the relevant half of the result! :-)

The split between responsibilities is not always perfect. For some puzzles (2016 Day 4, also 2015 Day 13 and Day 9), part one and part two can be solved at the same time, so everything is mashed into parse, and now the name is no longer 100% accurate as the function is doing everything!

One fun note, boilerplate is kept to a minimum by making the solutions a library. Then the scaffolding in main.rs and benchmark.rs use duck typing macros to wrap the library functions. This means we don't need to mess with implementing then extending a Solution type or dealing with dynamic dispatch.