# Performance

How fast are CoreEngine and CoreEngineClaim, really? Both plugins are measured with automated benchmark tests that run on every test pass. This page summarizes the results and puts them into perspective.

For context: a Minecraft server has **50 milliseconds** per tick (20 ticks per second). Everything that happens on the main thread has to fit into this budget. That's why CoreEngine **never** writes to the database on the main thread, but instead on its own background thread.

Test system: AMD Ryzen 9 9950X, Windows 11, Java 25. On different hardware the absolute numbers shift, but the orders of magnitude stay the same.

## CoreEngine

| Measurement | Throughput | Duration per operation |
|---|---|---|
| Reading a balance (`/balance`, placeholders) | 61 million/s | 0.016 µs |
| Money transaction including saving to disk | 489/s | 2.0 ms |
| Single database write | 297/s | 3.4 ms |
| Single database read | 126,800/s | 7.9 µs |
| `/baltop` with 10,000 accounts (worst case, no cache) | 590/s | 1.7 ms |
| Parsing time strings (`2h30m` for mutes/bans) | 1.7 million/s | 0.59 µs |

What this means:

- **Reading balances is practically free.** Even if every event on the server queried a balance, it would not be measurable.
- **Money transactions don't slow down the server.** On the main thread, a deposit costs less than a microsecond, the actual saving happens in the background. The 489 transactions per second are the limit of the background thread, which corresponds to roughly 29,000 money transactions per minute under sustained load.
- **`/baltop` is uncritical even with 10,000 accounts**, the result is additionally cached for 30 seconds.

## CoreEngineClaim

The most important path in the claim plugin is the question "which claim is this position in?". It gets asked on practically every protection event: breaking or placing a block, opening a chest, a PvP hit, redstone, pistons. Measured against a world with **2,000 claims**, 100 of which have 5 subdivisions each:

| Measurement | Throughput | Duration per operation |
|---|---|---|
| Position is inside a claim | 183,500/s | 5.5 µs |
| Position is inside a subdivision | 64,600/s | 15.5 µs |
| Position is in the wilderness | 366,000/s | 2.7 µs |
| Creating a claim including overlap check | 6,650/s | 150 µs |

What this means:

- **The protection check is extremely fast.** Even in the most expensive case, more than 3,000 checks fit into a single tick before even 1 ms of the 50 ms budget is used up. A server with 100 protection events per tick (which would already be a lot) uses less than 0.2% of the budget for this.
- **The wilderness is the cheapest case**, which is good, because that's where most events happen on survival servers. The cost doesn't grow with the total number of claims, only with the claims in the respective chunk.
- **Claim creation feels instantaneous**, even when checking for overlap against thousands of existing claims.

## Conclusion

> **Note:** Neither plugin has a path that endangers the server tick. Everything frequent runs out of memory in the microsecond range, everything slow (disk writes) runs on its own thread. The data structures scale: 2,000 claims or 10,000 accounts change practically nothing about the response times.