OverlapParams with FilteredDescendants extremely laggy with a lot of instances

[dobdev (Dob)]

Reproduction Steps

Create like 50,000 instances or so in a folder:

Run a check similar to this every .2 seconds

local overlapParam2 = OverlapParams.new()
overlapParam2.FilterDescendantsInstances = {workspace.Collectibles}
overlapParam2.FilterType = Enum.RaycastFilterType.Whitelist

local in_range = workspace:GetPartBoundsInRadius(character.PrimaryPart.Position, 15, overlapParam2)

Expected Behavior
I expect it to work smoothly with no lag

Actual Behavior
Once it starts using “GetPartBoundsInRadius” the game gets extremely laggy:

Workaround
Workaround i found was not using .FilterDescendantsInstances and .FilterType and instead manually checking if the Instance is in the folder:

for _,v in ipairs(in_range) do
	if v.Parent == workspace.Collectibles then
		collect(v)
	end
end

Micro profiler when using the workaround:

Completely smooth

Issue Area: Engine
Issue Type: Performance
Impact: Moderate
Frequency: Constantly
Date Last Experienced: 2022-01-05 00:01:00 (+01:00)

[regexman (reg)]

What did you expect? That’s like 50,000 so don’t expect it to be perfect, running smoothly, 60 fps, no lag at all, sus

[Orbular3]

I wouldn’t have thought it would be an “Engine Bug”. And to repeat what @regexman said, it’s perfectly normal to expect performance issues when using something like GetPartBoundsInRadius with 50,000 parts in one place

[dobdev (Dob)]

If I’m able to make it smooth by using the workaround, shouldn’t it also be easy to make FiilteredDescendants smooth too?

[tnavarts]

The reason that this doesn’t work well is that the whitelist / blacklist actually has to be fully evaluated into a flat set of BaseParts with the current raycast / region query implementation. That is, before the query begins, all of the descendant BaseParts which are included by the whitelist / blacklist have to be identified and added to a set that will be used by the query.

This works more efficiently than lazily evaluating whether candidate BaseParts should be ignored by looking at their ancestry for the typical query, but hits a performance cliff once you reach a certain number of BaseParts included by the whitelist / blacklist.

The resolution is that you should avoid filter descendants lists which include an excessively large quantity of parts (directly, or indirectly through being descendants of one of the items).