- Reduced beacons
- Partially reduced, shared beacons
- Partially reduced, nonshared beacons
- Full beacons
No, adding additional beacons as a "hurry up and wait" do not help performance. Neither does it appear to hurt performance. If you can save other entities or improve other aspects of the design with additional beacons they likely should be added.
Often in builds you will beacon assemblers beyond the useful work capacity of the recipe chain. For a simple example, 1 red-science assembler with 12 beacons of coverage requires 0.32 copper-plate furnaces of the same beacon coverage. In a DI chain (direct insertion) where one furnace DI's to one assembler, the one furnace would idle roughly 68% of its time. If we instead were to have only 3 beacons on that furnace, it would run at roughly 97% capacity.
When we look at what is gained by reducing beacon count, we can identify a couple potential factors that could change performance. For one, the crafting machine probably spends more calculations for the same output. On the flip side, fewer beacons means fewer entities to calculate power consumption for (and if your solar still includes roboport or radars, those will have a performance impact too). There likely is some overhead to getting put to sleep or waking up. In most cases the number of inserter swings on inputs/outputs will not change, but on some very fast recipes the number of items available to swing could be improved with more beacons, which would reduce overall inserter swing count.
This test will be comparing 4 close to identical designs, with the main variable being the beacon count on the furnaces. This is a red science design that includes DI chains of all the constituent raw materials. Each of the designs was built on the same coordinates and then number of beacon adjusted based on test case. Designs were cloned the same number of times to a large number of copies, yielding over 800k red science packs produced per minute. A 2k x 2k area was pregenerated in all maps to prevent any new chunks from generating during the benchmark.
A benchmark of 9200 ticks was performed 5 times per map, and the best tick per run was taken.
At first glance, it looks like we have no clear differentiator between the various testcases.
After sorting the timings per tick, some sort of difference might be there, but it's hard to tell.
When taking the 500 tick rolling average, we can see long term fluctuations in the performance of the testcases. While the full reduced case was technically faster than the rest, it was only by 1.5%. The longer term fluctuations are an order of magnitude more significant, so if we happened to measure a lucky 9200 tick "window" we could easily observe a 1.5% difference that didn't actually exist.
There doesn't appear to be a large difference between any of the tested cases. I would prioritize other factors than reducing or increasing beacon count.
It could be interesting to further investigate boosting very fast recipes or other long period cycles, and if any such scenarios exist.
As a theoretical example, a machine buffers up to 12 output items, and every once in a while 24 items are demanded in short succession. If we can craft 12 items in the time it takes for an inserter to swing, we would cause 2 swings, but if we were slower than that, it would incur 3 swings. If such a scenario existed, it could be a case for additional beacons.