Javascript's setTick is much slower than Lua's Citizen.CreateThread

FiveM Resource Development Discussion
,
1

I have a simple resource made with Javascript, and I want to add some logic which runs once every 1000ms. In order to do this, I am using setTick, as suggested in the documentation: setTick - Cfx.re Docs

It works as intended, however resmon shows severe underperformance compared to its Lua counterpart Citizen.CreateThread.

When using a blank resource with only one clientsided script with ONLY the following content:

setTick(() => { }); // CPU Inclusive Time: ~0.05ms

… the CPU (Inclusive) time inside resmon shows 0.05ms time. Removing the code completely makes the resource run at 0.0ms.

The time in resmon is also 0.05ms when doing the following:

setTick(async () => {
    // The following should wait 1000ms before the next tick
    await new Promise(res => setTimeout(res, 1000));
});

However, if I instead use a .lua file so I can use Citizen.CreateThread in combination with Citizen.Wait, as following:

Citizen.CreateThread(function()
    while true do
      print("Performance test!")
      Citizen.Wait(1000)
    end
end)

… in this case, resmon shows up a 0.00ms CPU time for my resource.

I’ve also noticed that using setInterval with an interval of 1000ms, like following:

setInterval(() => { }, 1000);

…also does the same thing - the resource’s CPU time jumps to 0.05ms from 0.0ms. Is it, maybe, that setTick relies on setInterval, which might be slow?

I’ve also done a profiler recording, which you can find attached:
ucjobs3 (2.8 MB)

Am I doing something wrong? Is resmon showing incorrect values for javascript files?

2

did you find any fixes to make this faster?

3

I got my answer here: Javascript’s setTick is much slower than Lua’s Citizen.CreateThread · Issue #1653 · citizenfx/fivem · GitHub

"The JS ScRT doesn’t implement ‘bookmark’-style scheduling yet, and the V8 C++ API has somewhat more overhead than even the Lua C API does.

Do note that 50 microseconds is still very much negligible and this won’t go up much more with actual code."

4

Thanks, got pretty much the same answer from another guy aswell as i only ran one javascript script so the runtime runs alongs the script. But thanks anyway

5

Apparently the times are much shorter in 2024, however, there seems to be a bug when restarting a JS script, generally the time that is 0.01ms changes to 0.04ms and remains at that value after restarting. But if we stop and start again back to 0.01ms

[image]

1 Like