Hmm, GetPartInPart() a bit laggy

I basically borrowed the script from a button game I was making that was never completed. I can’t see why it would lag the framerate or latency I am not sure yet. This is the first RunService I’ve used in this game and there isn’t much parts in it atm so I am unsure what is happening. The games not happy the second I run it but before I added this script it seemed fine. What am I missing?

Spawn part which paths to target (working) --added in collision groups for parts and character
Part reaches destination and gets detected
Once detected do stuff and delete part/model


local RunService = game:GetService("RunService")

local food = script.Parent -- basically the hitbox
local spawns = workspace.Spawns -- models with a humanoid and HumanoidRootPart

local function onTick(dT)
	local primaryParts = {}
	for _, part in pairs(spawns:GetChildren())do
		local humanoidRootPart = part:FindFirstChild("HumanoidRootPart")
		if not humanoidRootPart then continue end
		table.insert(primaryParts, humanoidRootPart)

	local params =
	params.FilterType = Enum.RaycastFilterType.Include
	params.FilterDescendantsInstances = primaryParts

	local inPart = workspace:GetPartsInPart(food, params)
	if #inPart > 0 then
		local numPart = #inPart
		print("Part found in food"..numPart)
		--get player leaderstats
		--add food value formula to food.Value
		--destroy ant
		--table.remove the correct ants primary part (necessary?)
		print("No Part found in food")


Seems to detect properly it’s just not happy.

Probably because you’re printing this every frame. Maybe removing the printing will fix the lag?

robloxapp-20240318-1636549.wmv (739.8 KB)
Here’s what’s happening. Runservice should be able to handle complex computations. I checked my CPU and the Game processes and the framerate was dropping in the 40fps’s for some reason but as you can see it feels much worse.

instead of heartbeat, use a while loop with a decent amount of wait time in between each loop and see if it’s better.

This is the original script for the button game and it doesn’t lag at all even now.
All it does is turns the button lights on and off.

I just don’t get why this one works and the other one lags.

Did you add some wait time in between? If so, try reducing the wait time to something like 0.1 if it’s really necessary. Something extremely fast like calculating every frame will cause tons lag.

Shouldn’t need to. I mean if I was calculating heavy physics computations then I may need to worry about that but not for a simple print statement.

Runservice itself seems fine in a new game.

A couple questions:

1- The big one, do you really need to be running this every frame? Spatial queries can be expensive depending on the number of parts you have, and this will scale up with the number of parts inside your overlapParams. Even if you’re checking every .1 seconds or so, you should still be getting decently high fidelity detection, and you’d then be reducing the number of GetPartsInPart calls by 90%.

2- How many parts do you have inside your overlapParams?

3- How big is food?

4- Do you only need to be detecting 1 part or do you need more than 1? If the former, set overlapParams.MaxParts (iirc that’s what it’s called) to 1

Some suggestions:

1- Maybe look into using parallel for your GetPartsInPart call as it’s a write parallel function

2- Reuse your overlapParams instead of creating them on the fly every frame

3- Reduce the number of GetPartsInPart calls

If none of these work, or you need help with an implementation, can you provide us with either a pic of how your workspace is set up, or, preferably, a place file in which you can get this lagging to occur?

Kind of yeah, I could use a touch event but at end game multiple players generating many models per second will be colliding with the food part in question. This way seems way more efficient and use friendly.

Also I think it’s the game that’s broken since I wrote a new spacial query in a new game and it ran just fine. idk what was with the old game (it was a refurbished script practice game that was emptied of all parts and scripts).