Threads and Wait in FiveM: loops that do not eat frames

Almost every FiveM performance problem comes back to one construct: a while true do loop with Wait(0) inside a thread. It is the right tool for drawing things every frame and the wrong tool for nearly everything else. Understanding what Wait actually does — and how to make a loop sleep when it has nothing to do — is the single highest-value habit a FiveM developer can build.

FiveM Lua threads are coroutines managed by the runtime’s scheduler. They do not run in parallel on other CPU cores; they take turns. When a thread calls Wait, it hands control back and asks to be resumed after that many milliseconds (or next frame for Wait(0)). A thread that never waits never hands control back — the game hangs.

CreateThread(function()
    while true do
        -- do something
        Wait(1000) -- then sleep one second
    end
end)

At 60 frames per second, a Wait(0) loop runs 60 times a second; at 144 fps, 144 times. Whatever is inside — natives, distance checks, table walks — is multiplied by that. One such loop is fine; twenty of them, each checking a dozen markers, is how a client ends up with dozens of milliseconds of script time per frame and visible stutter.

The standard pattern: sleep long by default, and only drop to Wait(0) while the player is close enough to need per-frame work.

local SHOP = vector3(25.7, -1347.3, 29.5)

CreateThread(function()
    while true do
        local sleep = 1000
        local dist = #(GetEntityCoords(PlayerPedId()) - SHOP)

        if dist < 15.0 then
            sleep = 0
            DrawMarker(2, SHOP.x, SHOP.y, SHOP.z, 0, 0, 0, 0, 0, 0, 0.3, 0.3, 0.3, 255, 255, 255, 180, false, true, 2, false, nil, nil, false)
            if dist < 1.5 and IsControlJustPressed(0, 38) then
                -- open the shop
            end
        end

        Wait(sleep)
    end
end)

Far away, this costs one distance check per second. Near the shop it runs every frame, because drawing a marker and reading a key press must. That single change often takes a resource from 0.5 ms to 0.01 ms in resmon.

Starting one thread per location multiplies the overhead. Keep one loop that checks all locations, and use the closest distance to decide how long to sleep:

CreateThread(function()
    while true do
        local pos = GetEntityCoords(PlayerPedId())
        local closest = math.huge
        for i = 1, #Config.Shops do
            local d = #(pos - Config.Shops[i].coords)
            if d < closest then closest = d end
            if d < 15.0 then
                -- draw this shop's marker
            end
        end
        Wait(closest < 15.0 and 0 or math.min(2000, math.floor(closest * 10)))
    end
end)

Open F8 and run resmon 1. Your resource’s CPU time should sit near 0.00–0.02 ms when the player is nowhere near anything it handles. How to read the monitor is in resmon and resource time.