FREE TOOL · PERFORMANCE

FiveM profiler analyzer

The profiler tells you the truth about which resource is eating your frame, and then hands it to you as a Chrome timeline that is pinned to one frozen DevTools build and shows thousands of unlabelled bars. Drop the capture here and get the answer instead: the resources ranked by their own time, the loops inside them, the worst frames as flame charts, and what each pattern usually means. Nothing is uploaded — the file is read in this tab.

1. Record while it is actually bad. The profiler records a fixed number of frames from the moment you ask, so start it when the server is full and the stutter is happening — not at four in the morning on an empty server. In the F8 console or the server console: profiler record 500. Five hundred frames is about eight seconds at 60 fps and is plenty.
2. Save it as JSON, not as the default. profiler saveJSON mycapture.json. The similarly named profiler save writes a binary msgpack file that nothing will open, including this page — although it will recognise it and tell you so rather than failing silently. Server captures land beside run.bat; client captures land in the FiveM application folder.
3. Drop it in and read the findings first. They are ordered by how much they matter, not by what the file happens to contain most of. Anything marked serious is either over the frame budget or a measurable per-frame cost; anything marked for information is there so you stop wondering about it.
4. Sort the resource table by self time, not total. Self time is a resource's own code. Total includes everything it triggered elsewhere, so a resource that fires an event into five others looks enormous by total and may be doing almost nothing itself. The thing to rewrite is at the top of the self column.
5. Open the loop table and look at the frames column. A loop present in 420 out of 421 frames is running on every frame. If its cost per frame barely moves, nothing in it is gated — that is the shape of a draw loop with no distance check, or a table rebuilt from scratch every frame. The file name and line range next to it is the function to open.
6. Then prove it. Stop the resource you suspect, capture again, and compare the median tick. If the number drops by roughly what the table said it would, you have found it. If it does not, the cost moved and the resource was only the messenger — which is exactly the mistake a single capture makes easy.

The documented profiler page covers the commands profiler record, profiler status, profiler saveJSON and profiler view, and says the result is loaded in the Chrome DevTools performance panel. It does not describe the file's structure at all: it does not contain the word traceEvents, any field name, or the commands profiler save, record start, record stop or resource. Everything on this page about the structure was read off the emitting source, Profiler.cpp, rather than guessed — but because it is undocumented it is not a contract, and Cfx.re can change it without telling anybody. The parser here is deliberately tolerant: it accepts a bare event array and complete events with a duration field as well, even though current FiveM writes neither, and the What the file holds tab shows you exactly what it found so you can see when the shape has moved.

1. A Wait(0) loop with a body. The thread appears in nearly every frame and costs real time in each one. Measured, not inferred: the capture holds the frame count and the per-frame cost. The fix is almost never to make the body faster — it is to run it less often. Two speeds in one thread is the usual answer: a slow outer loop that decides whether anything is nearby, and a Wait(0) inner loop that only spins while it is.
2. A draw loop with no distance gate. Same shape as above, plus a cost that barely moves from the cheapest frame to the most expensive. Nothing in the loop returns early, so it pays for the marker whether you are standing on it or across the map. Inferred from the flatness, because the profiler cannot see the draw call. Get the player coordinates once, compare squared distances, and skip the body outside the radius.
3. An un-cached lookup inside the loop. This one the file cannot see directly at all, and it is the most common single cause of the two above. PlayerPedId() or GetPlayerPed(-1) called every frame, often several times, when the value changes only when you respawn. Cache it outside the loop and refresh it on the spawn event.
4. A NUI or callback storm. Reference calls — the game calling back into Lua through a stored function — happening several times per frame. Counted, not inferred. An interface almost never needs updating at frame rate: one message every 100 ms carrying the whole state beats ten a frame carrying one field each, and nobody can see the difference.
5. A query blocking a server tick. A single slice holding the thread for more than ten milliseconds with nothing nested inside it. Measured. On a server this stops everybody at once, and it is nearly always a synchronous database call or an HTTP request waited on in the handler. The analyzer tells client and server captures apart before giving the advice, because the fix is different.