Minecraft Bedrock Script Profiler: Read Self Time, Total Time, and Call Count

Evidence boundary: Microsoft’s current Minecraft Creator documentation was rechecked on August 25, 2026. MineBrush did not run Minecraft, a Bedrock add-on, script, device, world, Realm, server, or benchmark for this article. Every number in the sample table is invented and exists only to teach the reading method.

The Minecraft Bedrock Script Profiler is useful when a scripted experience feels slow and you need a better question than “is this add-on laggy?” It records which functions ran during a bounded session, how much time belonged to each function, how much time included work called below it, and how often the function appeared. That evidence can point you toward code worth inspecting. It cannot prove the cause of a player’s hitch, rank devices, or establish a universal healthy threshold from one capture.

Quick answer: what the profiler tells you

Microsoft’s current script-debugging guide documents four fields in the result: function name, self time, total time, and call count. Read them together:

• Function name identifies the recorded function.
• Self time is time spent inside that function itself.
• Total time includes the function and functions it called.
• Call count records how many times the function ran during the captured session.

A high total-time entry is a place to open, not a guilty verdict. If total time is much larger than self time, inspect the called work below it. If self time is also large, inspect the function’s own body. If call count is unexpectedly high, ask what schedules or repeats the function. The word unexpectedly matters: a frequent lightweight callback and an accidentally repeated expensive scan are not the same problem.

Run a bounded profile from the official workflow

1. Use a disposable copy of the world or development experience. Record the displayed Bedrock build and the exact behavior-pack/script release before changing anything.
2. Choose one short, repeatable player route: the same world area, action sequence, entities, and menu state each time.
3. Start the profiler with /script profiler start.
4. Play through the chosen route normally. Microsoft’s guide says to run the experience for a few minutes; keep comparison passes consistent rather than chasing an arbitrary duration.
5. Stop the capture with /script profiler stop.
6. Open the generated .cpuprofile file in Visual Studio Code, as directed by the official guide.

Do not silently change render distance, player count, active packs, experiments, entity population, or the route between comparison passes. A profile is only comparable when the surrounding work is comparable. If you cannot reproduce the same scene, describe the capture as an observation rather than a benchmark.

The official page confirms the commands and output type on the source-check date. It does not establish that the commands are available with identical permissions, file locations, or UI wording in every retail build, Preview build, device class, Realm, hosted server, or account role. Treat command availability as a publication-day check, not a permanent promise.

Read the four fields without inventing a threshold

Synthetic example: invented values, not a benchmark

The following table is an original MineBrush teaching fixture. Names and values are made up. “Sample time units” are not measurements, milliseconds, game ticks, device results, or recommended limits.

In this invented fixture, sample:mainTick looks expensive by total time but spends little time in its own body. The next move is to expand its call tree, not delete the coordinator. sample:scanNearbyBlocks keeps its cost in the function itself, so the query and loop deserve attention. sample:updateIndicator is cheap per call but appears often; the correct question is whether that frequency matches the design.

Use a comparison sheet, not a single “lag” label

For each pass, record the exact world copy, Bedrock build, active behavior/resource packs, Script API dependencies, experiments, player count, scene, route, start/stop sequence, and profile filename. Then write one observation: for example, “the same route produced a higher share in the scan function after this code change.” Do not convert that into “all devices lose FPS” unless you separately measured frame behavior on declared devices under a controlled plan.

If you are comparing a script change, alter one factor at a time. Keep the original profile, make the smallest code or scheduling change, repeat the same route, and compare the same fields. A second pass that differs in player behavior, entity count, world area, or active packs does not isolate the code change.

When you are diagnosing a third-party add-on, do not redistribute its archive or publish private code just because a function name appears in your profile. Share the creator’s project URL, release, your displayed Bedrock build, a concise reproduction route, and the smallest useful profiler observation. Use the Bedrock add-on troubleshooting checklist to capture the surrounding install state first.

Turn a signal into a safe next step

• High total time, lower self time: expand called functions and find where the time moves next.
• High self time: inspect loops, repeated lookups, data size, and work done inside that function.
• Unexpected call count: inspect interval frequency, event subscriptions, repeated initialization, and duplicate scheduling.
• Unexpected API work: check whether the same query is repeated and whether a supported API filter can narrow the requested objects.

Microsoft’s guide specifically recommends filtering API calls when the API supports it, reducing unnecessary frequency, and caching values that do not change instead of fetching them repeatedly inside a loop. Those are investigation patterns, not automatic edits. Confirm that the filtered query preserves the intended behavior and that cached state remains valid for the experience.

If the pack layers or activation state are unclear, first verify the Behavior Pack versus Resource Pack relationship. For mobile installation problems that occur before any script runs, use the Bedrock mobile add-on installation guide. The profiler starts after the script is present and running; it does not replace package validation or the Content Log.

What this profile cannot prove

A single .cpuprofile cannot prove that one add-on caused every hitch, that a function is slow on all hardware, that a server or Realm has the same workload, or that a high call count is wrong. It does not identify GPU pressure, network delay, storage stalls, world-generation cost, or unrelated native game work. MineBrush has not established universal self-time, total-time, or call-count cutoffs.

The exact file location, profiler availability, permission requirements, Visual Studio Code presentation, and naming quality remain environment-dependent unknowns for this package. Function names can also be too generic to establish which creator owns the code. If the result does not map cleanly to the pack you are studying, stop at “unresolved” instead of assigning blame.

Bottom line

Start and stop a bounded Script Profiler session, open the generated .cpuprofile, and read function name, self time, total time, and call count as a connected set. Use high total time and unexpectedly frequent calls to choose what to inspect next. Repeat the same route after one controlled change. Keep invented examples, real observations, and causal claims clearly separated.

Primary reference: Microsoft Learn — Debugging Scripts in Minecraft, Script profiling section, rechecked August 25, 2026.