Lag question: impact of llCollisionFilter

Hi all,

I have an script that uses a collision event. The object needs to output data when it collides with any AGENT, but not with anything else. Like this:

integer i;
collision_start(integer num)
{
for(i=0;i<num;++i)
if(llDetectedType(i) & AGENT)
dosomething();
}

I am trying to figure out ways to reduce lag, since up to around 30 avatars could potentially be wearing this script simultaneously (the script is attached to avatars.) They will be walking around on prim-floors, so collisions will be raised continually.

One thing I have considered, is whether applying the following filter would reduce, or increase lag:
llCollisionFilter("floor",NULL_KEY,FALSE);

This filter would mean that only collisions with stuff other than objects called "floor" would be passed....

What I'm wondering, is what is the processing overhead of the collision filter? Is it more, or less than just letting the collision events get raised and sent to my code above? I'm assuming it would be beneficial, but I don't *know* this. I have no idea how I would go about testing this, since normally if I want to compare code I can just time processing sections of them... But that doesn't seem possible to test here.

Does anyone know?

Per the old wiki:

"This does not make the object ignore collisions, it just filters the collision event. -KyrahAbattoir"

So the simulator would still be processing the collisions with the floor. All the filter is doing is acting like another "if" test.

So...
llCollisionFilter("floor",NULL_KEY,FALSE);
Would effectively adding the following psuedo-code into the start of collision event:
{
integer i;
for(i=0;i<num_detected;++i)
if(llDetectedName(i)!="floor"
dotherestoftheevent
}

Hmmm, if that's the case, I'm glad I asked, as using this function would've *increased* server load.

I was hoping it would be more efficient.

I think by having the simulator filter it instead of the script iterating through the collisions itself, you'd improve performance... I just assume simulator would be able to throw away the unwanted collisions faster than the script would, and the script would have less collisions to iterate through. Eager to hear others' input

Stupid experiment number 3829:
Not perfect because I wasn't on an empty island but out of curiosity I put 30 of these scripts into a prim and attached it to my foot Then I watched Script (ms) time and when it was pretty steady I started walking around. Looked like only 0.3-0.7ms which is an acceptable amount for server load considering it was 30 scripts. Heck part of that would have been the llSay's anyway. So guess if you keep all of the code in the script pretty clean it should be alright.

You could even try testing it the same dumb way with different itinerations of the script. Would suggest finding an empty island with a script time of 0.2 to 0.5 to get more reliable results thou.

string name;
default
{
	state_entry()
	{
		name = llGetScriptName();
	}
	collision_start(integer total_number)
	{
		llSay(DEBUG_CHANNEL, name);
	}
}

I agree. The sim is probably always going to check for filters before sending them to the script anyway.. The sooner you can throw unwanted events away, the better.