Speed Demon 2026: Every Millisecond Is a Soul

Most hackathons ask you to build something impressive.

Speed Demon asks a different question.

How fast can you make it run?

Not how fast your laptop says it runs.

Not how fast it ran once.

Not how fast you claim it is.

The organizers run your code themselves, on the same machine, against the same dataset, using the same benchmarking harness.

And then they rank what comes back.

Welcome to Speed Demon 2026, a 72-hour online performance championship by Hackathon Raptors where every millisecond counts, every optimization has a cost, and correctness is non-negotiable.

The challenge is simple:

Same task. Same data. Same machine. Beat the reference implementation.

And no, writing everything in C and hoping for the best is not necessarily going to win.

About the Hackathon

Speed Demon 2026 is a 72-hour online performance engineering competition organized by Hackathon Raptors.

Instead of building another application, participants optimize computational workloads that deliberately start with slow reference implementations.

You get the task specification.

You get the dataset.

You get the reference implementation.

Your job is to produce a solution that returns exactly the same output while using fewer resources and running faster.

At a glance

• 🌍 Online and open to participants worldwide
• ⏳ 72-hour competition
• 📅 October 30 – November 2, 2026
• 💰 $2,000 total prize pool
• 👥 Solo participation or teams of up to 4
• 💸 Free to participate
• 🧠 Five performance engineering tracks
• 🐳 Docker-based evaluation
• 🏆 Individual track awards and an overall championship
• 🤖 AI coding assistants allowed

The competition runs from October 30 at 18:00 UTC to November 2 at 18:00 UTC.

Participants can enter as many tracks as they want, but completing at least three tracks is required to qualify for the overall Speed Demon title.

The winning strategy is not simply to write the shortest code or achieve the lowest runtime on one task.

It is to build correct, efficient software that performs consistently across different workloads.

Why Another Performance Competition?

Performance optimization is one of those engineering disciplines that everyone talks about and surprisingly few people measure properly.

You will hear things like:

"This implementation is faster."

"This algorithm should scale better."

"Rust will definitely beat Python."

"This data structure is more efficient."

Sometimes those statements are correct.

Sometimes they are guesses dressed up as engineering decisions.

Speed Demon replaces those arguments with measurements.

Every submission is evaluated against a published reference implementation, using a controlled environment and a fixed scoring methodology.

The interesting part is that execution time is only one component of the score.

Consider two implementations.

Implementation A finishes in 0.4 seconds but consumes enormous amounts of memory, ships thousands of lines of complicated code, and relies on several heavyweight dependencies.

Implementation B finishes in 0.9 seconds, uses a fraction of the memory, and has a simpler implementation with fewer dependencies.

Which one is better?

That depends on the trade-offs.

Speed Demon makes those trade-offs explicit through a published efficiency coefficient.

You cannot win simply by optimizing one metric while ignoring everything else.

And you cannot win with an incorrect answer, no matter how fast your program is.

Five Tracks. Five Different Engineering Problems.

Speed Demon has five tracks, each designed to test a different set of skills.

You do not need to enter all five.

Choose the workloads that match your strengths, or challenge yourself by entering several.

Track A: Ingest

Parse 3.1 million log lines. Aggregate the results. Make it fast.

The task involves processing 312 MB of structured log data.

You must calculate per-endpoint request counts, p50/p95/p99 latency percentiles, and hourly error rates.

The reference implementation performs the task correctly, but inefficiently.

It reads lines, splits fields, parses timestamps using a date library, stores latency values, and sorts them later to calculate percentiles.

Every one of those operations is an opportunity for optimization.

You might investigate:

• Custom line parsing instead of general-purpose readers.
• More efficient timestamp parsing.
• Reducing temporary string allocations.
• Replacing expensive hash-based operations where appropriate.
• Improving cache locality and memory layout.
• Computing percentiles without sorting every individual latency.
• Reducing allocator overhead.
• Processing records efficiently across multiple threads.

The challenge is figuring out which optimization actually matters.

A faster parser will not help much if timestamp parsing remains your dominant bottleneck.

And a clever algorithm can still lose if its data structures cause excessive memory traffic.

Reference runtime: 41.2 seconds.

This is a good starting point for anyone interested in systems programming, parsing, and data processing.

Track B: Index

Build a search index. Answer 50,000 queries. Optimize both sides.

You receive a 250 MB text corpus and must build an inverted index that supports Boolean and phrase queries.

This track is particularly interesting because index construction and query execution are measured separately.

Build time contributes 40% of the combined time measurement.

Query time contributes 60%.

An implementation that builds an index incredibly quickly but answers queries slowly is not necessarily competitive.

You need to think about:

• Inverted index representation.
• Posting-list compression.
• Efficient intersection of posting lists.
• Boolean query execution order.
• Tokenization and indexing.
• Positional indexes for phrase queries.
• Memory consumption.
• The trade-off between preprocessing and query performance.

Phrase queries add another layer of complexity because the system must preserve token positions and match adjacent terms in the correct order.

The fastest data structure to construct is not always the fastest one to query.

That trade-off is the point.

If you enjoy search engines, databases, indexing systems, or query optimization, Track B deserves a serious look.

Track C: Join

The fast solution is easy. The edge cases are the actual task.

Track C involves parsing a 204 MB CSV dataset containing deliberately difficult input cases.

The file includes:

• Quoted commas.
• Escaped quotation marks.
• Embedded newlines.
• Mixed line endings.
• UTF-8 byte-order marks.
• Empty fields.
• Trailing spaces.
• Records that span multiple lines.

After parsing the input correctly, you must join it against a lookup table and produce sorted aggregates.

This is where assumptions become expensive.

A parser that splits every line on commas may appear to work on ordinary input.

It will fail when a quoted field contains a comma.

A parser that assumes one record per line will fail when a field contains a newline.

A solution that mishandles a byte-order mark may produce incorrect output even when the rest of the pipeline is perfect.

The interesting engineering questions include:

• Should you use a hash join or sort-merge join?
• How should you represent parsed fields?
• Can you avoid unnecessary allocations?
• How do you handle encoding edge cases without sacrificing performance?
• Can you process the data efficiently while preserving exact output semantics?

A parser that is three times faster but produces the wrong output scores zero.

This track rewards engineers who understand both performance and correctness.

Track D: Traverse

Five million edges. Two thousand shortest-path queries.

Track D gives you a directed, weighted graph containing 5 million edges and asks you to answer 2,000 source-target shortest-path queries.

This is the algorithms track.

The gap between a competent implementation and an excellent one can be substantial.

Potential approaches include:

• Efficient graph representations.
• Adjacency-list and compact-array layouts.
• Priority queue optimization.
• Bidirectional shortest-path search.
• Preprocessing for repeated queries.
• Improved memory locality.
• Contraction hierarchies or other suitable acceleration techniques.

Preprocessing is allowed, but its cost is included in the measured runtime.

That means you cannot simply ignore the time required to construct an index or auxiliary structure.

You must decide whether the upfront cost is justified by faster query execution.

This is a classic build-versus-query trade-off.

The right approach depends on the graph, the query workload, the available memory, and the cost of preprocessing.

If you enjoy graph algorithms and want a competition where constant factors matter alongside asymptotic complexity, this is your track.

Track E: Compress

Make the data smaller without losing a single bit.

Track E focuses on lossless compression of a 100 MB mixed corpus containing:

• English text.
• Structured logs.
• JSON records.
• Binary sensor data.

The score balances compression ratio and decompression throughput.

You cannot win by producing a tiny archive that takes forever to decompress.

You cannot win by decompressing instantly while barely compressing anything.

The engineering challenges include:

• Identifying patterns in different data types.
• Choosing appropriate compression representations.
• Balancing compression ratio against runtime.
• Improving decompression throughput.
• Managing memory usage.
• Handling heterogeneous input efficiently.
• Ensuring exact round-trip correctness.

General-purpose compression libraries that solve the entire task are prohibited for this track.

You need to implement the compression approach yourself, within the published rules.

The interesting part is that this track changes the efficiency coefficient slightly: compressed size replaces peak memory as the corresponding resource metric.

It is the most direct exploration of the speed-versus-size trade-off in the competition.

How the Competition Works

Every track gives participants the same fundamental ingredients:

• A published task specification.
• A fixed reference implementation.
• A defined dataset format.
• A published execution environment.
• A scoring formula.
• A set of correctness and sandbox requirements.

You develop your solution locally and package it in a Docker image.

The organizers build and execute that image.

Your program reads its input from /data, writes the required output to /out, and exits successfully.

The dataset is mounted read-only.

Networking is disabled.

The root filesystem is read-only, with a limited temporary directory available for scratch space.

Your implementation must work within the specified CPU and memory limits.

This is not a benchmark where everyone submits numbers from different machines and hopes they are comparable.

The organizers run your code. Your reported timings do not count.

The machine

The official benchmarking environment is a dedicated Hetzner EX44 server in Helsinki, Finland.

The published hardware specification includes:

• Intel Core i5-13500 processor.
• Six physical performance cores available to submissions.
• Twelve hardware threads.
• 8 GB memory limit per submission.
• Docker with cgroups v2.
• Debian 13.
• Network access disabled during builds and scoring.

The CPU resources are pinned, and turbo boost is disabled to reduce variability.

Every submission is evaluated under the same execution constraints.

This matters because performance results are meaningful only when the measurement environment is controlled.

Your laptop is useful for development and profiling.

The official machine determines your score.

The Scoring System: Speed Is Not Everything

Speed Demon uses an efficiency coefficient called K.

The coefficient combines five ratios against the reference implementation.

The published formula is:

K = (Tref/T)^0.40 × (Mref/M)^0.20 × (Sref/S)^0.15 × (Dref/D)^0.15 × (Xref/X)^0.10

Here is what each factor means.

T: Wall time — 40%

How long does your implementation take to execute?

The official harness runs the program five times.

The highest and lowest timings are discarded, and the mean of the remaining three becomes the measured runtime.

This is the most heavily weighted factor.

M: Peak memory — 20%

How much memory does your implementation consume?

The harness reads the peak memory measurement from the execution environment rather than trusting a value reported by your program.

Using more memory to achieve lower runtime can be a valid engineering trade-off, but it comes at a cost.

For Track E, compressed size replaces peak memory in this factor.

S: Source size — 15%

How large is your normalized source code?

The source is measured after the specified canonical formatting, comment removal, and identifier normalization.

The goal is to account for source size without rewarding meaningless tricks such as renaming every variable to a single character.

Readable code is allowed to be longer.

It simply has to justify its cost.

D: Dependency weight — 15%

How much does your solution depend on external runtime dependencies?

Dependencies are allowed, subject to the track-specific restrictions, but they are not free.

The published calculation includes non-standard-library runtime dependencies and vendored source size.

A zero-dependency implementation can gain an advantage on this axis, even before its runtime is considered.

X: Scaling — 10%

How does your solution behave when the input becomes larger?

The harness compares your runtime at different input sizes against the reference implementation's scaling behaviour.

This helps identify solutions that perform well on small inputs but deteriorate as the workload grows.

Each factor is capped at 50×.

The weights are fixed before kickoff, so participants know the trade-offs before writing their code.

Turning K into points

The efficiency coefficient is converted into a speed score using a logarithmic scale:

Speed Score = 100 × ln(K) / ln(25)

The score is clamped between 0 and 100.

The important reference points are:

• K = 25: 100 speed points.
• K = 5: 50 speed points.
• K < 1: Zero speed points.

Why logarithmic scoring?

Because performance optimization becomes increasingly difficult as you push beyond an already fast implementation.

Improving a solution from 1× to 2× can be relatively straightforward.

Improving it from 12× to 24× may require completely rethinking the algorithm or data representation.

The scoring curve reflects that reality.

Your final score

Machine-measured performance accounts for 65% of each track's score.

The remaining 35% comes from human judging:

• Code quality: 15%.
• Optimization technique: 12%.
• Optimization log: 8%.

The overall championship requires at least three completed tracks and uses the geometric mean of the track totals.

That prevents one spectacular result from carrying two weak results.

To win overall, you need to perform well across multiple workloads.

Correctness Comes Before Optimization

There are four important evaluation gates.

Fail any required gate, and the submission receives zero for that track.

1. Exact output

Your output must match the expected SHA-256 hash.

Not approximately.

Not with the same values in a different order.

Exactly.

The specifications define the output format, ordering, and formatting rules. Sample datasets and expected hashes allow you to verify your implementation locally.

A solution that produces the correct answer four times out of five is still incorrect.

2. Performance floor

The published rules include a performance floor for the overall title.

A submission must be within 10× of the fastest correct submission in its track to satisfy this requirement.

3. Timeout

Each track has a hard timeout based on the reference implementation's runtime.

A program that hangs or exceeds the limit is not treated as a successful slow implementation.

It is a failed run.

4. Sandbox compliance

Submissions must respect the restrictions on networking, filesystem access, and dataset modification.

Precomputed answers, attempts to access protected data, or other methods of bypassing the intended task can result in disqualification.

This is a performance competition, not a contest to find loopholes in the benchmark harness.

What You Need to Submit

Each track submission needs a repository that can be built and evaluated without manual intervention.

The expected deliverables include:

• Public GitHub repository.
• OSI-approved open-source license.
• Dockerfile.
• Required source code and build scripts.
• README.md.
• PERF.md.
• .speed-demon.toml.

Your Dockerfile must build without network access.

The resulting program must follow the track's input/output contract and satisfy the execution requirements.

The optimization log matters

PERF.md is not supposed to be a marketing document.

It should record what you actually tried and measured.

For example:

• The baseline implementation took 41 seconds.
• Replacing a hash map with a compact array reduced runtime to 8 seconds.
• Manual line parsing reduced it to 2.1 seconds.
• A SIMD optimization made timestamp parsing slower, so it was reverted.

That is useful engineering documentation.

It demonstrates that you understand your bottlenecks, tested your assumptions, and made decisions based on evidence.

Failed experiments count, too.

Sometimes the most valuable optimization lesson is discovering why an apparently clever change made the program worse.

The 72-Hour Strategy

Seventy-two hours sounds like a lot until you start optimizing five different workloads.

The obvious mistake is to spend the entire weekend chasing the biggest theoretical speedup without first establishing a correct baseline.

A more sensible approach is to work in stages.

Stage 1: Make it correct

Read the specification carefully.

Implement the straightforward solution.

Verify the output against the sample dataset and expected hash.

Do not start with clever optimizations before you understand the exact output requirements.

Stage 2: Establish a baseline

Run the implementation locally.

Measure runtime and memory.

Use profiling tools to identify where the time actually goes.

Do not guess.

If timestamp parsing consumes 60% of runtime, optimizing an unrelated loop is unlikely to move the needle much.

Stage 3: Optimize the dominant bottlenecks

Prioritize the changes most likely to improve your score.

Depending on the track, that might mean:

• Choosing a better algorithm.
• Reducing allocations.
• Improving memory locality.
• Replacing expensive data structures.
• Optimizing parsing.
• Changing the indexing strategy.
• Improving query execution.
• Reducing unnecessary dependencies.

Measure after each meaningful change.

Keep the changes that help and revert the ones that do not.

Stage 4: Verify every optimization

Run the correctness checks again.

A faster solution that fails the output hash is worthless.

Also test the solution under the same resource limits and execution assumptions used by the official harness.

Stage 5: Prepare the final submission

Make sure the Docker image builds offline.

Verify that the program reads from the correct directory and writes the expected output.

Complete PERF.md, README.md, and .speed-demon.toml.

Do not leave packaging and documentation until the final minutes.

Stage 6: Decide whether to enter more tracks

If your first track is strong and stable, consider entering another.

If your current solution is still incorrect or poorly optimized, adding another track may reduce your chances of doing either well.

For the overall title, you need at least three completed tracks.

For individual awards, a strong specialist submission can still be valuable.

Choose your strategy accordingly.

AI Tools Are Allowed

You can use AI coding assistants, including Claude Code, Cursor, Codex, GitHub Copilot, local models, and other development tools.

The competition does not score you based on whether you used AI.

It evaluates the software you produce.

AI can help generate an initial implementation, explore alternative algorithms, explain profiling output, or automate repetitive experiments.

But it cannot replace verification.

Generated code may contain incorrect assumptions, unnecessary allocations, inefficient data structures, or subtle correctness bugs.

If you cannot explain why your implementation is fast, your optimization log will expose that gap.

Use AI to accelerate the engineering process.

Then measure, test, and understand what you ship.

Prize Pool: $2,000

Speed Demon has a total prize pool of $2,000 across six awards.

Award	Prize
Speed Demon — Overall Champion	$800
Runner-up	$400
Third Place	$200
Highest Efficiency Coefficient	$200
The Lean Award	$100
Write-Up Side Quest — 3 winners	$300 total

Speed Demon — $800

Awarded to the overall champion with the highest geometric mean across at least three tracks.

The goal is to be fast everywhere, not just on one workload.

Runner-up — $400

Awarded to the second-place team on the overall leaderboard.

Third Place — $200

Awarded to the third-place team in the overall championship.

Highest Efficiency Coefficient — $200

Awarded to the submission with the largest efficiency coefficient recorded on any individual track.

This award recognizes exceptional optimization on a specific workload, even if the team does not qualify for the overall title.

The Lean Award — $100

Awarded for the best efficiency coefficient achieved with the smallest normalized source.

This recognizes solutions that achieve strong performance through effective engineering rather than unnecessary complexity.

Write-Up Side Quest — $300

Three winners receive $100 each for publishing an insightful account of their optimization journey.

Document the bottleneck you discovered, the changes you tested, the experiment that failed, or the small change that produced a major improvement.

The focus is on technical insight, not audience size.

Important Dates

All times are in UTC.

Event	Date
Registration opens	October 2, 2026
Team formation closes	October 26, 2026
Specifications and harness published	October 28, 2026 at 18:00 UTC
Sample datasets released	October 30, 2026 at 06:00 UTC
Hackathon kickoff	October 30, 2026 at 18:00 UTC
Code freeze	November 2, 2026 at 18:00 UTC
Official scoring runs	November 2–4, 2026
Judging window	November 3–12, 2026
Write-Up Side Quest closes	November 10, 2026
Winners announced	November 13, 2026

The full specifications, reference implementations, and scoring harness are published before kickoff.

The final datasets are released at kickoff, and the leaderboard opens.

Final scoring uses holdout data generated from the same distributions with previously unseen seeds.

The scoring formula is frozen before the competition begins.

Rules You Should Know

Before registering, keep these requirements in mind:

• Teams must contain 1–4 members.
• Solo participation is allowed.
• Any programming language is eligible if it builds offline in a Linux container and runs on x86-64.
• All project code must be written during the official 72-hour competition window.
• Research, algorithm planning, documentation reading, and environment preparation are allowed before kickoff.
• Code must not be committed before kickoff.
• AI coding assistants and development tools are allowed.
• Dependencies are permitted but contribute to the dependency-weight calculation.
• Track-specific restrictions on libraries must be respected.
• Output must match the reference implementation exactly.
• Precomputed answers and input-specific shortcuts that bypass the intended task are prohibited.
• Docker builds must work without network access.
• Submissions must respect CPU, memory, timeout, and sandbox restrictions.
• Repositories must be public at code freeze and use an OSI-approved open-source license.
• The required documentation and submission metadata must be included.
• The official harness determines the benchmark results.
• At least three completed tracks are required for the overall Speed Demon title.

Read the official specifications and rules for the complete requirements before submitting.

Who Should Join?

Speed Demon is a good fit for developers who enjoy understanding how software behaves under pressure.

You might be a:

• Systems programmer who cares about cache lines and memory allocation.
• Data engineer who has strong opinions about parsing and aggregation.
• Backend developer who wants to optimize a slow pipeline.
• Database engineer who enjoys indexes and query execution.
• Competitive programmer who wants to explore real-world performance constraints.
• Algorithms enthusiast who likes finding better approaches to difficult problems.
• Compression developer interested in the trade-off between size and throughput.
• Student who wants to go beyond implementing standard algorithms.
• Developer who has ever opened a profiler just to understand why something was slow.

You do not need to be an expert in every track.

You need a willingness to experiment, measure, and improve.

Why Speed Demon Is Different

Most hackathons ask:

"What can you build in 72 hours?"

Speed Demon asks:

"How much better can you make something that already works?"

There are no points for a convincing pitch.

No reward for claiming that your implementation is optimized.

No advantage to submitting benchmark results from a more powerful laptop.

The organizers run your code.

The output must be correct.

The measurements determine the performance score.

The judges evaluate the engineering behind the implementation.

That changes how you approach the entire competition.

A theoretically optimal algorithm can lose to a better-engineered implementation.

A faster solution can lose points because it consumes too much memory.

A tiny program can still fail if it is incorrect.

A clever optimization can make the code slower.

And the only way to know is to measure.

That is what makes performance engineering interesting.

It is not about writing code that looks fast.

It is about producing evidence that it is fast, understanding why, and knowing what trade-offs you made.

Final Thoughts

Speed Demon 2026 is a different kind of hackathon.

Five tracks.

Five distinct engineering problems.

A fixed machine.

A published scoring formula.

A 72-hour deadline.

And a reference implementation waiting to be beaten.

Build the straightforward solution first.

Make it correct.

Measure the bottlenecks.

Optimize the important parts.

Test every change.

Document what worked and what did not.

Then do it again.

The strongest submission will not necessarily be the one with the most complicated algorithm or the fewest lines of code.

It will be the one that combines correctness, measured performance, efficient resource usage, and sound engineering decisions.

Every millisecond is a soul.

Join Speed Demon 2026

🌐 Event Website: https://speeddemon.dev/

🦖 Hackathon Raptors: https://raptors.dev/

💬 Discord: https://discord.gg/xfYPDZYqeh

📅 October 30 – November 2, 2026

⏳ 72-hour online performance championship

💰 $2,000 total prize pool

👥 Solo or teams of up to 4

💸 Free to participate

Five tracks. One reference implementation to beat. One machine that does not care how good your idea sounded.

Make your code faster. Make it leaner. Prove it with measurements.

See you on the leaderboard.