Running it

Performance

How much work the plugin does each tick, where that work goes, and how to check the numbers on your own hardware rather than taking this page's word for it.

Measuring it yourself

Run /trimbound timings. It gives you three numbers per effect, plus how many players are currently wearing a trim at all.

Trim effect cost (3 players currently wearing a trim)
 - redstone: 0.031ms/tick, 0.010ms/call, max 0.412ms, calls 6240, errors 0
 - amethyst: 0.008ms/tick, 0.024ms/call, max 0.190ms, calls 694, errors 0
 - iron: 0.001ms/tick, 0.000ms/call, max 0.021ms, calls 6240, errors 0
Total: 0.040ms per tick (0.080% of a 50ms tick)

How expensive any of this is depends on how many players wear the relevant trim and what happens to be around them. None of that can be worked out from the source code, which is the reason the command exists.

What runs every tick

Work is scheduled per wearer, not per player. Each player wearing a trim that does something gets one repeating task, and that task is cancelled the moment they take the armor off. Nobody else on the server is visited at all.

So the cost scales with how many people wear trims, not with how many are online. Six wearers on a five hundred player server costs you six players' worth of work.

Working out what a player is wearing is the operation most likely to be repeated, so it is cached and recalculated only when their armor changes, when they change world, or after one second as a safety net. A player standing still costs almost nothing.

Effects that run less often than every tick are also staggered, so two hundred wearers on a four tick scan spread across four ticks instead of all landing on the same one.

The part that scales with your server, not the plugin

Most of the costs above scale with how many players use a trim. One of them does not.

The redstone trim listens for redstone changes, and that event fires for every redstone change anywhere on the server: every farm, every clock, every rail. On a busy server that is thousands of events a second regardless of whether a single person is wearing the trim.

That handler is written to do as little as possible. When nobody is using the trim it exits on one check. When somebody is, it takes two map lookups to decide whether the block is one it is driving, and does nothing further if it is not. If you are going to watch one number after installing this on a large server, watch the redstone line while a clock is running.

Folia

Trimbound runs on Folia using the same jar. There is no separate build and nothing to configure.

Per tick work goes on each player's own entity scheduler, which means it executes on the region thread that owns that player and the blocks around them. The redstone trim tracks every block it drives by counting how many players are asking for it, so a block is only ever written from the region that owns it, and two players standing on the same wire combine into the stronger signal.

If something throws

An effect that throws an exception is logged once with its stack trace and then keeps running. Further failures from the same effect are counted but not logged, because an effect failing every tick would otherwise put twenty stack traces a second into your console. The errors column in the timings output shows that count.

One effect failing does not stop the others.

Using an external profiler

The built-in timings are per effect and nothing more. For anything deeper, Spark gives you a real sampling profiler and attributes time properly across the whole server:

/spark profiler start --timeout 300
/spark profiler stop