At least from a quick glance at the code :
Each placed conductive pipe unit uses a separate implementation of the IPipeTransportPowerHook, meaning a pipe going from one end of a chunk to another will do many different requestEnergy and receiveEnergy calls, as well as every consumer or engine attached to those pipes -- though these calls are very simple and modern compilers are quite good about optimizing things,thirty times three if statements aren't bad, but a thousand times three if statements can add up. They also change graphics on load, which adds to the cost.
I /think/ conductive pipes also check for neighbors as part of their power consumption routine, which adds a bit of extra performance and memory access cost (and a mess of six-bounded for loops). The system relies pretty heavily on block updates, which can't be good.
Conduits, on the other hand, act as a network: the only updates the actual BlockConduit class does involve when they are first placed, wrenched, or removed, adding themselves to LinkedLists*. The actual heavy lifting is done by a separate GridEnergy that holds those LinkedLists (I'm not sure if there is one per set of connected conduits or per engine, but my guess is per set of connected conduits). That means that no matter how long the set of conductive pipes, that there's only one call to transferEnergy for each consumer (and engines use a single method call per engine in the PowerProviders side). The downside is that the transferEnergy method is drastically more complicated, with several nested for loops, and Java's LinkedLists aren't exactly cheap to start with. A conduit run a thousand blocks between a dozen engines and a dozen consumers involves a lot fewer potential messes with conduits than conductive pipes, but if you're only going from a couple engines to a couple consumers, it's going to do a bit of unnecessary calculations and take up more memory than needed.**
* This might be better as an ArrayList -- Java's ArrayLists are much, much faster to find things in and cost a huge amount less memory, at the cost of being slower to add or remove items to in worst-case scenarios. But that change is probably premature optimization, and ArrayList resizing is a pain to code in a robust way, and I'm not that experienced with Java optimization so I'd have to sit down with a timer to be sure. It's only really relevant for folk with hundreds of engines in a network, at which point you have other problems.
** But, since we're only talking a few devices, this usually won't matter much. Performance for O(n) isn't very scary with an n of two. Could matter if you have a lot of sets of one engine feeding one device in a chunk, but even if that's something that the BuildCraft devs want people to do, that's not really how the Steam Boiler folk run.
Each placed conductive pipe unit uses a separate implementation of the IPipeTransportPowerHook, meaning a pipe going from one end of a chunk to another will do many different requestEnergy and receiveEnergy calls, as well as every consumer or engine attached to those pipes -- though these calls are very simple and modern compilers are quite good about optimizing things,thirty times three if statements aren't bad, but a thousand times three if statements can add up. They also change graphics on load, which adds to the cost.
I /think/ conductive pipes also check for neighbors as part of their power consumption routine, which adds a bit of extra performance and memory access cost (and a mess of six-bounded for loops). The system relies pretty heavily on block updates, which can't be good.
Conduits, on the other hand, act as a network: the only updates the actual BlockConduit class does involve when they are first placed, wrenched, or removed, adding themselves to LinkedLists*. The actual heavy lifting is done by a separate GridEnergy that holds those LinkedLists (I'm not sure if there is one per set of connected conduits or per engine, but my guess is per set of connected conduits). That means that no matter how long the set of conductive pipes, that there's only one call to transferEnergy for each consumer (and engines use a single method call per engine in the PowerProviders side). The downside is that the transferEnergy method is drastically more complicated, with several nested for loops, and Java's LinkedLists aren't exactly cheap to start with. A conduit run a thousand blocks between a dozen engines and a dozen consumers involves a lot fewer potential messes with conduits than conductive pipes, but if you're only going from a couple engines to a couple consumers, it's going to do a bit of unnecessary calculations and take up more memory than needed.**
* This might be better as an ArrayList -- Java's ArrayLists are much, much faster to find things in and cost a huge amount less memory, at the cost of being slower to add or remove items to in worst-case scenarios. But that change is probably premature optimization, and ArrayList resizing is a pain to code in a robust way, and I'm not that experienced with Java optimization so I'd have to sit down with a timer to be sure. It's only really relevant for folk with hundreds of engines in a network, at which point you have other problems.
** But, since we're only talking a few devices, this usually won't matter much. Performance for O(n) isn't very scary with an n of two. Could matter if you have a lot of sets of one engine feeding one device in a chunk, but even if that's something that the BuildCraft devs want people to do, that's not really how the Steam Boiler folk run.
