Any tips on reducing CFraming lag?

Help and Feedback Scripting Support
1

I need some tips on ways I can reduce lag when CFraming parts every frame. When I CFrame 100 parts every frame, it reduces my fps by almost 40 which I want to try to reduce.

3 Likes
2

You need to pinpoint where the lag is coming from? Server lag, replication lag, machine lag?

First thing im wondering is if youre CFraming them on the client or server?

3

I am CFraming the part on the client which causes the most lag.

4

Send the code youre using please.

5 
local function Update(delta)
	task.desynchronize()
	
	local origin

	local Moving
	local CurrentHeight
	local LookVector
	local MovingTo
	local WalkSpeed

	local direction = (MovingTo - origin).Unit
	local newCFrame

	if Moving then
		local distance = (MovingTo - origin).Magnitude
		local timeToReachTarget = distance / WalkSpeed
		local alpha = math.clamp(delta / timeToReachTarget, 0, 1)
		local lerpPosition = origin:Lerp(MovingTo, alpha)
		newCFrame = CFrame.lookAlong(lerpPosition, LookVector == Vector3.new() and direction or LookVector)
	else
		newCFrame = CFrame.lookAlong(origin, LookVector == Vector3.new() and direction or LookVector)
	end

	task.synchronize()
	HumanoidRootPart.CFrame = newCFrame
end
1 Like
6

First, How are you calling that function.

Second, take that all out of parallel. CFrame manipulation is inherently tied to Roblox’s rendering and physics systems, which are primarily single-threaded. CFrame should be read-only in parallel.

7

I’m calling the function using this line of code:
RunService.PostSimulation:ConnectParallel(Update)

8

try binding on render stepped, without use of parallel luau. even using ConnectParallel, there will still likely be issues writing to a CFrame in an unsynchronized thread.

9

Somehow just now realizing that youre updating the CFrame after resyncing.

How many actors are you using, and can I see a micro profiler dump/SS.

1 Like
10

Using parallel LuaU in this case is gonna worse the performance. It would make sense if there were more calculations to do. If you really want to use Parallel LuaU, you need a better code for it. But for now just don’t make it Parallel as it makes no sense to use it.

If you could calculate all parts CFrames in one script and store the results as a table, you could use the BulkMoveTo() function which would make it faster.

1 Like
11

If you haven’t already, definitely check the micro profiler. I’ve been consistently setting and tweening over 1,000 assemblies before seeing the performance hit you’re seeing. That tells me this is less likely a CFrame overhead issue, and more likely to be something else - parallel overhead. The micro profiler should be able to show you what’s stalling your frames, even down to how long certain calls and indexes take in some cases.

There’s nothing inherently wrong with doing all this CFrame math in parallel and then setting properties. The problem is when the time it takes to initialise an actor in parallel negates the time you save by parallelizing.

Lets say it takes 5ms to initialise an actor and 1ms to run your math (completely made up numbers, nowhere near accurate). If you run every single update in parallel, it’ll take 6ms for each update. The problem is, your computer doesn’t have 100 cores to actually run every single actor at once. Lets say you have 4 cores for simplicity. Each core is going to have to run 25 actors in serial, even though it’s doing it in parallel with the other cores. That’ll take 150m. 125ms of that is spent initialising actors! Considering running it in serial takes 100ms, you can see why parallelism might actually slow you down - which is what I’d guess is happening here.

What you could do instead is collate multiple tasks into a single actor. Lets say in our imaginary situation we use the absolute most optimal number of actors - 4, one for each core. Each actor will run the maths for 25 updates, then push the property updates once they all serialise. Each actor is gonna take 5ms to initialise, then take 25ms to do the math. That means that all 100 updates are being ran in 30ms, compared to 100ms or even 150ms! That’s the perfect situation for parallelism.

Since users have variable core counts and it’s difficult to get the exact count for peak efficiency, you’ll rarely match your cores to actors. But that’s fine. There’ll always be a little bit extra overhead. But your best move is to take a look at the micro profiler and have a go at moving multiple updates under the same actor, you should seem some improvement.

2 Likes
12

I found out that the problem must be that I am updating too many attributes every frame. I had the server update the attributes so that other scripts could get them.

13

Instead of individually CFraming each part, try to group them together and apply the same CFraming operation to all of them at once. This can help reduce the overhead of multiple CFraming operations.

You could also have CFramed parts that are static and don’t need to move independently, consider using Part Welding to group them together. Welding the parts can reduce the number of individual parts that need to be CFramed, which can improve performance.