How to see the RunService heartbeat in-game?

I have a cannon that turns based off of the RunService.HeartBeat:Wait(), and sometimes in game it gets laggy and it causes the cannon to turn slowly. How can I see the ingame heartbeat rate? There has surely got to be some way.

use RenderStepped:Wait() or :BindToRenderStep

In-game, you can use Shift + F4.

You might want to clarify your question more about “ingame heartbeat rate”. Heartbeat functions are received a delta time argument if this may help you which is the time since the last heartbeat.

What are you asking?

Heartbeat returns an argument referred to as a deltaTime, or the time since the Heartbeat event was last fired. This can be seen using

print(game:GetService("RunService").Heartbeat:Wait())

Alternatively as previously stated you can use Shift+F4 and look at the 4th line under “FPS” which will give you the Heartbeat rate, although I can’t make a verifiable statement on it’s accuracy.

Why are you turning a cannon based on Heartbeat anyway? That’s only going to cause lag, and is pointless when you consider a cannon’s rotation has no reason to be manipulated on each frame. I recommend switching over to a system using wait() as that runs ~25 times a second as opposed to running ~40-100+ times a second depending on the player’s FPS.

wait() isn’t reliable either because it can change compared to a heartbeat time length that never varies too much.

If the threads were full, wait() may very well take way longer than 0.03 seconds that it is approximately at commonly.

Heartbeat should be fine for rotating a simple cannon since he’s just doing a property change or two.

But performance is inherently the issue here?

His entire concern is that his game is laggy when turning the cannon which is a situation that can be rectified by slowing down the time between increments, as mentioned he is trying to adjust these properties too fast - there is no need to update an orientation every frame, it is undoubtedly effecting the performance and generating the lag that OP made the post about.

Oh sorry, I’ve meant to say that he probably has a laggy heartbeat because the game is lagging based on the player’s FPS if I assume correctly.

I’ll scratch what I said about performance complaint but I’ll keep the rest of the details as those are true.

However, updating orientation per frame is not really a problem if its just for a few objects. His problem is just a little vague so we can’t understand what he’s doing per frame in specifics, whether it be changing orientation on one object or multiple.

Hi everyone, sorry for the inconsistencies; inherently I don’t understand heartbeats well enough.

My cannon is held together by a cframe loop; every part inside is anchored, and I turn the cannon using Model:SetPrimaryPartCFrame on a single part which in turn rotates the rest of the model, using a loop. For the loop, I use Heartbeat:Wait() as my increment system.

I use the Heartbeat on the server side; I’ve been hearing from others that the heartbeat on the server side fires ~40 or ~60 times a second, so I use this for my raycasting and turning of the cannon (I’ve seen a few raycast examples using heartbeat at as a wait). I’ve tried using wait(1/30) as a replacement for Heartbeat:Wait().

So yes bug performance is the issue here, but the real purpose of asking this was to figure out a better way to turn the cannon beside Heartbeat. I asked how to see heartbeat in game, to see if I could diagnose some problems in my game to reduce the amount of heartbeat lag (or however you call it), so that my cannon can turn faster without lag. But you guys make it clear that there are better ways; what better ways of turning a cannon (using a cframe loop) should I use? I’ve tried renderstepped, and wait(1/30 or some tiny increment, both are kinda laggy imo unless I’m doing something wrong).

If you need more info just let me know

You can check the ServerJobs in the developer console both in studio and in game. It tells you how many times Heartbeat runs per second, along with how long it took in milliseconds.