Same performance issue from #617. It's been reintroduced at some point since those changes.

A simple setup containing ten lasers disconnected from power with an inactive table:

Time per tick per laser is an average of 0.07ms over a 2 minute profiling period.

I do not currently have proper profiling data using jvisualvm/warmroast, but can get it if required.

I see the problem.
@SpaceToad a soultion would it be that there would be a registry for Placed LaserTargets, and the lasers check in the list which one they could use. That would decrease lag imensly at the beginning because the lasertargets are not really much placed in world if you have BC only. What do you think? It could be placed inside of the API (a interface that store these 4 functions: onPlaced, onBreaking, getRandomTarget, getAllTargets),

void onPlaced(ILaserTarget par1),
void onBreaking(ILaserTarget par1),
ILaserTarget getRandomTarget(World world, int x, int y, int z, int range),
List getAllTargets();

What do you think @SpaceToad?

another thing to that should be done is don't have lasers look for targets if they don't have power

I agree with @AEnterprise.
@Speiger I think delay is no problem.

@AEnterprise that would increase performance but also increase the time that lasers need to link to an assembly table. ^^" Solutions to that are pretty hard.

@RagaRBM i think the delay would not happen even thanks to the way how SafeTimeTrackers work. As far as i understand the SafeTimeTracker reads the worldtime for delays and co. (I personally would go for the System Time (computer clock) but that is just a longer number for the same stuff). Just wanted to tell that. And yeah Raga i agree with @AEnterprise too. But in this case the most machines get Constantly powered because first the Powergen itself (see Railcraft) is more wastefull when you stop and restart it as when you constantly drain it. So they wasting power to prevent wasting fuel. NoneSense of anyKind.

@RagaRBM that still does not solve the problem. People get lasers Always powered, because thats easier than make it shutdown power if theres no work.
The BlockChecking for targets take to long. Because checking 726 blocks every Time is a lot of work. If you would not place 10 lasers it would not be so laggy. Decreasing it from 726 blocks to check the amount of LaserTargets will decrease the lag extremly.

@Speiger @AEnterprise @RagaRBM - actually, a very easy way to fix it would be to have Blocks implement ILaserTargetBlock. Block checking is VERY fast compared to TEs (by a HUGE margin) and should solve all the lag issues. Please share your input.

that could work, but could give issues with toggeling active/inacive for the lasers

@AEnterprise - you could getTileEntity later, but it would still only get TEs of blocks which are laser targets, lowering the lookup area quite severely.

that could work, another aproach could be waiting for the blockPlacement event that is comming to forge (or use the implementation of eureka) and have the blocks look for lasers on placement and add thereselfs to a list, the lasers would then only look once if they are placed down

The BlockPlace event is a bit messy and will remain a bit messy, IMO.

@asiekierka it migth be messy but i don't mind a little mess if it drasticly reduces lagg