# Minecraft Tutorial Datapack Optimization

> Minecraft Tutorial: Optimizing Data Packs 数据包优化教程：Profiling 性能分析（/perf 专用服务器 F3+L单人游戏、debug/profiling/<time>-<world>-<version>.zip server/profiling.txt、函数性能 tick>commandFunctions/tick>levels>ServerLevel tick>scheduledFunctions）、Best Practices 最佳实践（Reduce Running Commands 减少运行命令：/schedule 自调度循环 hook #minecraft:load、periodic_tick 实体谓词 每实体频率门控、Advancements on players 进度代替@a扫描 推荐使用advancement revoke、Enchantments on mobs 附魔效果服务器端每实体运行）、Optimize NBT Operations 优化NBT操作（NBT访问/修改昂贵 保存/修改/重载 创建新实体；推荐 execute if items entity 代替nbt匹配、predicates代替nbt匹配、item modifiers代替data commands、Command storage caching 命令存储缓存 复制到storage一次 处理后写回）、Reduce execute subcommands 减少execute子命令（effect give直接代替execute as run、条件移入选择器参数、丢弃无用execute run）、Optimize Target Selectors 优化目标选择器（添加type= 除非每个实体类型都重要、减少@e使用 合并选择器用@s执行函数、添加distance= 当实体附近）、Optimize Macro Functions 优化宏函数（避免不必要宏、缓存约8个参数集 拆分16参数宏为两个8参数宏显著加速）、Alternatives 替代方案（Player-distance gating 玩家距离门控 标签活跃实体、return run匹配 互斥情况提前返回、Binary trees 二叉树 极端情况数 O(log n)匹配）。

- Skill: `zmjjkk123-hub/minecraft-tutorial-datapack-optimization` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zmjjkk123-hub/minecraft-tutorial-datapack-optimization`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zmjjkk123-hub/minecraft-tutorial-datapack-optimization/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ZMJJKK123-hub (https://skillmd.com/u/zmjjkk123-hub)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/zmjjkk123-hub/minecraft-tutorial-datapack-optimization

---


# Tutorial: Optimizing Data Packs

Java Edition only. How to optimize commands and datapacks.

## Profiling

Run `/perf` on a dedicated server (or F3+L in single-player), then open `<server root>/debug/profiling/<time>-<world>-<version>.zip` (clickable in chat) and read `server/profiling.txt`. Function performance data: `tick > commandFunctions` and `tick > levels > ServerLevel[<world>] <dimension> > tick > scheduledFunctions`.

## Best Practices

Minecraft is complex; no rule always applies — experiment.

### Reduce Running Commands

The single best optimization: don't run commands every tick. Extend periods or avoid tick loops.

- **`/schedule`**: self-scheduling loops (`schedule function example:loop/2t 2t` inside the function) instead of `#minecraft:tick`; hook the start into `#minecraft:load`.
- **Entity `periodic_tick` predicate**: if global scheduling is bad (e.g. stacking sounds), the `periodic_tick` entity predicate gates per-entity frequency (still runs a selector, so slightly worse than schedule).
- **Advancements on players**: avoid `@a` scans by using an advancement (e.g. `minecraft:tick` trigger with entity_scores/location conditions) whose reward function runs only when conditions change; remember to revoke it (`advancement revoke @s only example:player/score`).
- **Enchantments on mobs**: for non-player entities, enchantment effects (e.g. `minecraft:tick` + `run_function`) run server-side per entity; even "unused" slots like the saddle slot on zombies work.

### Optimize NBT Operations

NBT access/modification is expensive (the game saves the entity, modifies, and reloads it; a new entity is created on writes). Prefer:

- `/execute if items entity @s weapon.mainhand apple run ...` over `@a[nbt={SelectedItem:{...}}]`.
- Predicates over NBT matching: `@a[predicate=example:riding_pig]` with an `entity_properties` predicate (`vehicle.type`) instead of `@a[nbt={RootVehicle:{id:"minecraft:pig"}}]`.
- Item modifiers over data commands: `item modify entity @s contents {function:"set_count",count:10}` instead of `data modify entity @s Item.count set value 10`.
- **Command storage caching**: if ≥3 NBT commands remain, copy the NBT to storage once (`data modify storage example:temp custom_data set from entity @s item.components.minecraft:custom_data`), work on it, then write it back once.

### Reduce execute Subcommands

- `effect give @a[tag=hider] glowing` instead of `execute as @a[tag=hider] run effect give @s glowing`.
- Move conditions into selector args: `execute as @a[tag=hider,scores={timer=0..}] run ...` instead of `execute as @a[tag=hider] if score @s timer matches 0.. run ...`.
- Drop useless `execute run`: `say hi` instead of `execute run say hi`.

### Optimize Target Selectors

- Add `type=` unless every entity type matters: `@e[type=marker,tag=special_altar]`.
- Reduce `@e` usage: merge repeated selectors into one function using `@s`: `execute as @e[type=item] run function example:f/process_item`, then use `execute if items entity @s contents ...` inside.
- Add `distance=` when entities are near: `@e[type=marker,tag=test,distance=..1]` (entities load per chunk).

### Optimize Macro Functions

- Avoid macros when unnecessary: `execute store result score @s example run data get entity @s Age` instead of `$scoreboard players set @s example $(Age)`.
- The game caches ~8 used argument sets per macro function — split a 16-argument macro into two 8-argument ones for a significant speedup.

## Alternatives (risky or mediocre gains)

- **Player-distance gating**: at the entity: `execute as @e[type=item] at @s if entity @a[distance=..24] run ...`; with many entities, tag them once per interval: `tag @e[tag=!active.64,distance=..64] add active.64` / `tag @e[tag=active.64,distance=64..] remove active.64`, run from a `schedule` loop.
- **`return run` matching**: when cases are mutually exclusive, `execute if predicate some:1 run return run function some:1` ends the function early (only for single-branch execution contexts; `as @e` multi-branch runs only the first branch). Put more likely cases first.
- **Binary trees**: for extreme case counts (no macros possible), split by score ranges: root checks `0..127` / `128..255`, nodes halve recursively (`..63`, `64..127`, ...) — O(log n) matching.