-
-
Notifications
You must be signed in to change notification settings - Fork 0
Performance
🌎 Choose language: EN — English · RU — Русский
Short version: the defaults are fine, and the one setting worth touching is huds.tick-period.
Every tick-period ticks, for each player with a HUD visible:
- The values the HUD uses are resolved.
- Those values are fingerprinted and compared with the last tick's.
- If nothing changed, nothing else happens — no assembly, no packet.
- If something changed, only the blocks whose values changed are rebuilt, the head is taken from a per-player cache, and one boss bar title update goes out.
The expensive part of a HUD is not the arithmetic, it is the packet. Skipping it when the screen would look identical is where nearly all of the saving comes from, and it happens by default.
huds:
tick-period: 2 # ticks between updates; a tick is 50 ms| Value | Updates per second | Sensible for |
|---|---|---|
1 |
20 | the smoothest possible compass; can get expensive past a hundred players |
2 |
10 | the default. Compass motion still reads as smooth |
4 |
5 | numbers and bars only, no compass |
10 |
2 | a mostly static HUD on a very large server |
Raising it saves little on a static HUD, because a static HUD was not sending anything anyway. It mainly makes moving elements — the compass above all — step rather than glide.
- Your own value providers. A provider registered through the API runs once per HUD tick per player. A database query in there is the one reliable way to make this plugin slow. Compute on your own schedule and return a cached value.
-
PlaceholderAPI.
[papi:...]costs whatever the expansion behind it costs. Built-in values like[health]are field reads. - Compasses. The one element that changes on every mouse movement, so it is the one that genuinely sends packets every tick.
- Number of HUDs shown at once. Each is assembled separately. Showing four where one would do is four times the work.
Head elements download a skin once per player and cache the face. A failed or slow lookup falls back
to the built-in face and does not block anything. skins.timeout-seconds bounds the wait; on an
offline-mode server without SkinRestorer there is nothing to fetch, and skins.enabled: false skips
even trying.
HUD work runs on the player's own scheduler, so on Folia it lands on the region thread that owns the player rather than on one global thread. There is no separate Folia code path and nothing to configure — the same code is correct on both platforms.
Compilation happens on reload, not during play. Builds are deterministic: the same configuration produces a byte-identical archive, so the hash is unchanged and clients do not re-download a pack they already have. A reload that changes nothing costs the players nothing.