Skip to content

Conversation

@ianbanks
Copy link
Contributor

This reduces the part 1 time to 9 times lower; previously it took:

test year2025::day09::part1_bench ... bench:     134,158.57 ns/iter (+/- 4,533.71)

And now part1 and part2 are down to double digit microseconds:

test year2025::day09::parse_bench ... bench:       3,822.47 ns/iter (+/- 270.37)
test year2025::day09::part1_bench ... bench:      14,712.81 ns/iter (+/- 1,088.09)
test year2025::day09::part2_bench ... bench:      46,462.22 ns/iter (+/- 3,256.31)

It works by excluding "interior" tiles that could not possibly be part of the largest rectangle:

region

The comment of the filtering function get_potential_left_corner_tiles(...) explains it a bit more.

After filtering there are only around 50 tiles per corner.

It is possible to optimize part1(...) further so that it does fewer than the approximately 50x50 comparisons, but the performance gain is only about 15% (mainly due to the input being a circle or diamond: almost all of the top left corner points are to the left of the bottom right corner points, for example) and the resulting code is much more difficult to prove or reason about correctness.

As per CONTRIBUTING.md, I agree that I have authored 100% of the content, that I have the necessary rights to the content and that the content I am contributing is provided under the project license.

@maneatingape
Copy link
Owner

Nice solution. The overall speedup from my original is an impressive ~14x (668µs to 49µs).

@maneatingape maneatingape reopened this Dec 16, 2025
@maneatingape maneatingape merged commit 214ead7 into maneatingape:main Dec 16, 2025
4 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants