Just why is KSP Physics so slow? (NOT a Rant)

[Red Iron Crown]

I believe the purose of the physicsless flag if to effectively weld the parts to their parent and remove the need to run physics on them.

Sort of. Parts with the physicsless flag flipped have their masses added to the first physicsful parent part (as 5thHorseman mentions), this means that inertia calculations for that part do not need to be done. Some physics still applies though, massless parts still have joints that can be bent or broken. I've also read that there are issues with joints in Unity when parts of highly disparate masses are connected, these issues mostly disappear if the mass of the smaller part is made zero (this is why the 3.75m decoupler is physicsless).

There is one thing I don't understand: Why can't you just e.g. 'cut' a ship in two pieces and then let two threads (or in reality cores) calculate each half? KSP's tree structure means normally parts only have single connections. Shouldn't it be possible to make some process communicate said connection between the two threads? Maybe it would be somewhat more lenient or slightly lagging behind, but, without coding knowledge, it's hard to imagine what could go wrong in this case.

I mean, if we can communicate a thousand boxes touching between multiple cores, why not a single connection?

Xtoro mentioned the same thing earlier in the thread, and on the surface it seems like a good, simple solution. As I understand it there are a couple of issues with it:

- Multiple connections between the "branches" of the tree break this implementation, so struts and multiple docking port connections can throw a big monkey wrench in the plan. (This is relatively minor, though, as loops in KSP vessels are the exception rather than the rule.)

- A single thread is needed to manage the interaction between branches in a given tree. This thread must keep track of all the forces the other parts apply to the point of connection between the branches, a task that also scales at worse than O(n). So we'd be trading one difficult to thread task for another, hard to say whether there would be a net performance gain. (I've read some things suggesting ways to multithread this task, but they are still in academia as far as I know).

- More practically: The PhysX people are unlikely to put many development resources into solving this difficult problem. Large chains of constrained rigidbodies using mesh colliders are very, very rare in the gaming world, I can't think of another game that uses them as extensively as KSP does. So for the vast majority of their customers the existing methods for solving them are entirely adequate, PhysX development time is better spent on things that affect more of their customer base.

What I get confused about is PhysX, originally this was a hardware/software company purchased by Nvidia, and Then Unity 3d uses PhysX as the name of its physics engine, which may or may not be the same thing as apparently Unity upgrades to use PhysX, not the other way around.

Unity is a complete game engine, which includes things like asset management, development tools, UI tools, etc. PhysX is a component of Unity, a toolkit that handles physics computations. Each new version of Unity can include a newer version of PhysX as well, though often it remains the same to make transitioning from one version of Unity to another easier.

[Nigeth]

Long story short, Unity licensed PhysX as it's prime physics engine and integrated it into their engine.

I'd still rather use Havok if possible.

- - - Updated - - -

Splitting rockets like suggested would also reinforce the notion of KSP vessels being set-up like a tree with a single node at the top and allow for even less ways to have multiple connections between parts (think struts or decouplers for example). I'd rather they find a solution that made the setup of vessels more flexible (e.g. multiple radial decouplers per booster so that you don't need to stabilize them via struts)

[Temeter]

Xtoro mentioned the same thing earlier in the thread, and on the surface it seems like a good, simple solution. As I understand it there are a couple of issues with it:

- Multiple connections between the "branches" of the tree break this implementation, so struts and multiple docking port connections can throw a big monkey wrench in the plan. (This is relatively minor, though, as loops in KSP vessels are the exception rather than the rule.)

- A single thread is needed to manage the interaction between branches in a given tree. This thread must keep track of all the forces the other parts apply to the point of connection between the branches, a task that also scales at worse than O(n). So we'd be trading one difficult to thread task for another, hard to say whether there would be a net performance gain. (I've read some things suggesting ways to multithread this task, but they are still in academia as far as I know).

- More practically: The PhysX people are unlikely to put many development resources into solving this difficult problem. Large chains of constrained rigidbodies using mesh colliders are very, very rare in the gaming world, I can't think of another game that uses them as extensively as KSP does. So for the vast majority of their customers the existing methods for solving them are entirely adequate, PhysX development time is better spent on things that affect more of their customer base.

Thx for the answer, so there just isn't enough movement into that direction. I really hope one day devs finally figure out multithreading, it's lack is kind of a serious issue in many CPU-heavy games. Not only physics, but also stuff like pathfinding did cripple some RTS like SupCom. :/

[ferram4]

There are some problems with chunking up the vessel for multithreaded simulation as well.

The first one is that, if you've decided to go along with running the physics in separate threads, you eventually need to bring that data back together to the main Unity thread (or into one of the physics threads) to handle chunk interactions, and then certainly to the main Unity thread to actually do anything else in the game. The main risk with this is that the costs of synchronizing the threads from blocking the main Unity thread until it can proceed and the context switches on the processor can end up eating away at all of the performance gains.

The second one is that your physical system will end up being really funky at the borders of the chunks. The parts that connect chunks together will end up having forces on them that are much higher magnitudes than the other parts involved (simply due to the mass and inertia of the chunk as a whole, without any damping through other parts), which might lead to parts being spun off, shot through each other, or what have you if the forces are applied correctly, but from a large enough chunk. It'll be worse at higher timewarps. Connections between things with very disparate masses almost always results in bad things happening and is the source of a lot of wobble in KSP, particularly between small decouplers and large tanks, which have very high mass ratios.

The third one is that physical shenanigans like this risk violating conservation of momentum and energy even more than with the stock game. The physics engine already doesn't conserve these (not counting dissipation from damping in the constraints) simply due to integration error. Large forces on small objects (see above paragraph) requires a rather small timestep (read: more physics frames and computations per second) to prevent joints from wobbling back and forth before flying apart.

The fourth is that attempts to solve 2 and 3 will inevitably involve trying to only handle interactions between the chunks as a whole, with the parts inside basically disconnected from the other chunks entirely. This then leads to things being very sloppy at the chunk boundaries, where parts will end up moving relative to each other in very strange ways. Especially if one of the chunks has a lot of internal flexing going on, which is going to add a lot of motion between the orientation and position of the chunk as a whole and the orientation and position of the parts that are supposed to be the boundaries (remember, not just those parts, also the struts across the boundaries). No one wants to see their wobbly rocket made of one noodle turn into a wobbly rocket of multiple noodles flying in close formation until the joints break and it telefrags itself.

TL;DR: lots of physics issues can come up here, possibly more things to be called "Krakens," not even certain that it will result in a sufficient speedup to justify all the physics issues that will need to be ironed out. Not trivial at all, to say the least.

[TheTom]

The main risk with this is that the costs of synchronizing the threads from blocking the main Unity thread until it can proceed and the context switches on the processor can end up eating away at all of the performance gains.

I do not see this. As explanation: I develop highly real time systems for a living (say: financial automated trading) and we do a ton of multi threading. The issue here is that if every single simulated construct is not totally trivial, then you can handle the synchronization quite effectively in a separate thread. The trick being the not totally trivial - and if you assume a single construct (like a stage) has 20 parts or so, evidence is there that this is not trivial in itself, so the overhead will not be extreme. It requires a lot of good programming, though (mostly a queue and a signal when all constructs are calculated, not doing tons of super small locking).

The second one is that your physical system will end up being really funky at the borders of the chunks.

And THIS is the problem, as I see it now. That said, this still would be terrifically useful when applied intelligently:

* Payload can be packed into a separate construct which then goes into a box.... which is in the parent construct (the rocket). Until you evict the payload, this splits the physics. Amazingly most more complex rocket have most parts in payloads (one or multiple satellites) so this may work quite well. Especially if you add fairings and cargo bays.... hiding the internal construct... that can lead to an amazing simplification. When launching / in VAB measure max. allowed stress for a construct, then measure this during the simulation in the outer construct (like the rocket). As long as stress levels on the satellite inside the rocket are within parameters.... it is fine per definition.

* You may actually have non rigid bodies. Not joking. Ignore the "rocket" for a moment. Assume two frequent edge cases: A station with 2-3 docket shuttles and a for example mun base. All these could be seen as being "flexibly joined" if you reconstruct the connection parts to allow for flexibility (docking port EXTENDS a flexible mount, station parts are connected with flexible tunnels). The result is that you can safely handle quite an amount of "uncertainty" on them. Heck, given the Kraken's ugly appearance I would love some more cheats here anyway, as a player. What about "permanent" landing legs (pylons) that lock a part into the surface - and can then disable the physics.... You can make quite "physics light" bases if you realize that smaller forces simply are irrelevant once the part is anchored

Obviously the leaves the problem of multi construct collisions, but that is quite rare and if you do multiple constructs in multiple threads this may always happen (docking going bad for example). The results still would allow much large for example bases to be constructed

From what I read about PhysX though, the new version is a LOT better than the old. Not even talking about the simulation part - but it seems the current (Unity 4.x) version is quite crappy from the programming side (translates: ancient). I read somewhere that it basically is using X86 instruction set - with no extensions. The new version is supposedly a lot better, using for example SIMD instructions etc. This is purely programming side and should result in a good speedup. Baseline elements like this are part of the 3.x SDK

THAT BEING SAID - just reading through the PhysX documentation... https://developer.nvidia.com/sites/default/files/akamai/physx/Manual/Broadphase.html

Interesting read. Let me quote:

PxBroadPhaseType::eSAP was the default algorithm used until PhysX 3.2. It is a good generic choice with great performance when many objects are sleeping. Performance can degrade significantly though, when all objects are moving, or when large numbers of objects are added to or removed from the broad-phase. This algorithm does not need world bounds to be defined in order to work.

Ah, yes. That sounds like it is really what we face here.

PxBroadPhaseType::eMBP is a new algorithm introduced in PhysX 3.3. It is an alternative broad-phase algorithm that does not suffer from the same performance issues as eSAP when all objects are moving or when inserting large numbers of objects. However its generic performance when many objects are sleeping might be inferior to eSAP, and it requires users to define world bounds in order to work.

Hope they give that a try If they can (as in: after all, they use Unity - so the access to PhysX features may be limited).

Regarding the wobbling, btw. - I am not so totally sure that we are not looking at a... hm.... misunderstanding of how to program here. I mean, seriously, while most of the time KSP is quite realistic, the edge cases are horrific. Never done physics programming, but the system should calm itself down, not go wild out of control. This may well be a bug somewhere in the setup or code...

[Temeter]

Thanks again, this time to Ferram, that's a lot of interesting stuff. Well, stuff that goes wrong, but it does create the picture of a solution that creates more issues than it solves. Guess we'll rather have to put our hope in the upgraded version of Physx!

From what I read about PhysX though, the new version is a LOT better than the old. Not even talking about the simulation part - but it seems the current (Unity 4.x) version is quite crappy from the programming side (translates: ancient). I read somewhere that it basically is using X86 instruction set - with no extensions. The new version is supposedly a lot better, using for example SIMD instructions etc. This is purely programming side and should result in a good speedup. Baseline elements like this are part of the 3.x SDK

So that's actually one of the versions that were ancient the day it was written? As noted, there were a lot of speculations Ageia just used outdated code so you absolutely need their cards to have any resonable amount of performance using the effects.

I'd still rather use Havok if possible.

Compared to the version unity 4 uses? Definitly! It's about time for an upgrade. Luckily the current version turned out to be good enought for most more reasonable projects, but KSP is often enough about getting a step further.

Edited July 8, 2015 by Temeter

[TheTom]

@Temeter:

I am not sure. Occams Razor says to never aattribute to Malice what you can attribute to incompetence. I would say they rather did not care because they were supposed to run in the card anyway. Also, I am not sure how ancient PhysX is. I mean, in memory - I am not sure SIMD was around at the time they did their work. OTOH it makes me wonder what langauge it is written in.... because if that is C/C++, the use of SIMD etc. is pretty much a compiler switch (and proper structures, but those are "native" and should be thre anyway, i.e. a Vector3 is a Vector3 in code anway). If you use C# for example it is a "Mono yes, .NET from MS not at all until the new 4.6 runtime" thing. Yes, you can do optimizations, but the general use of something is.... pretty much a compiler switch. Unless you go assembler and do all that stuff manually I would really say that given they were Hardware focused... they likely just throw the software version around quick and VERY dirty.

NVidia also played this game for some time (Hardware in their own cards) bu then at one point must have realized that this is not working. The result now seems to be a lot of more - sensible decisions for the software side.

- - - Updated - - -

Just to put up 2 movies (granted, Havoc engine) that show where my "problems" understanding the performance are:

http://www.havok.com/physics/

Look at

Towards the end... starts 50 seconds in. Those must be more than a thousand parts all interacting. And yes, they may not be connected, but then they do push around piles of things. You really tell me that is less interaction than a rocket with 30 parts, some of which are not even physics controlled?

Destruction, 35 seconds in. This wall there gets torn into a LOT of individual pieces that again all seem to interact with each other. No, not ridig - but then they are not really "undfexible" either. Second 48+ - that car crashing into other cars... that is with all those parts exploding out LESS calculation than a rocket with 100 parts? When you look close you see all the fragments flying around are correctly hitting the other elements - so a TON of collision checks must occur.

My problem really is seeing how a fixed 30 or 50 part rocket can be more work to calculate than those tremendous ridiculous amounts of stuff flying around in those videos.

Oh, you want something larger?

- 1:30 Edited July 8, 2015 by TheTom

[Nigeth]

Havok is a different physics middleware.

The problem I have with PhysX is that it's not really a product but an NVidia marketing incentive. They bought Ageia so that they'd have something that they could use to promote their CUDA feature to gamers and game developers. They also bought Ageia to have something thyt would let them compete with Intel who had bought the company responsible for Havok two years earlier.

PhysX is there so that NVidia can promote CUDA to gamers. Similar to other NVidia technologies and GameWare features it will not work as well when used without an NVidia product or on competitor's technology. Similar to other technologies developed by NVidia it is likely to be intentionally crippled in one way or another if you use it on competitor's products.

At least the current version is finally somewhat well maintained and feature complete. It still works best in conjunction with NVidia cards though.

- - - Updated - - -

x86 Processors support SIMD instructions since the Intel Pentium 5/AMD K6-2 in 1997/1998 when Intel introduced MMX and AMD introduced 3Dnow.

[cantab]

I wonder how much impact not using primitives affects performance? KSP really suffers from that because rockets are mostly collections of cylinders and Unity offers no cylinder primitive.

[Red Iron Crown]

My problem really is seeing how a fixed 30 or 50 part rocket can be more work to calculate than those tremendous ridiculous amounts of stuff flying around in those videos.

That sort of thing is much easier to parallelize because all those objects are moving independently most of the time, threads only interact when an actual collision occurs (and that only affects those two parts for a frame or so), and it is likely that the colliders are primitives that have much cheaper collision calculation (because who cares if they carom incorrectly, it's just debris in an explosion and really only needs to look awesome). It's so parallelizable that it is useful to offload it to the massively parallel processor that most computers have, the GPU. Each thread has lower performance than it would on a CPU, but it's fast enough that a GPU compute unit can handle it in real time.

Parts in KSP use mesh colliders, so collisions are more computationally expensive, and they are constantly interacting with each other due to being connected rather than just bouncing off each other. They're really different problems.

It's too bad that physics engine development has been more focused on making things get destroyed prettily rather than simulation fidelity, but I guess that's what sells.

[TheTom]

Sure it is. Imagine how much more fun KSP would be, if you could build a 4000 part rocket, then put it on the launchpad and then put Jeb on the VAB and use a rocket launcher for an EPIC (physically correct) explosion (with terrain destruction and parts flying around). KSP Descructor edition (USD 59.99) would likely sell billions of copies

[Darnok]

Wait so if I use 80t fuel tank and put 300 solar panels on it physics engine will count that as 301 parts? That is very wrong, even 300 solar panels have very little impact on how 80t tank will fall, fly or whatever. And if 80t tank is going to hit something at 30+m/s I am sure solar panel won't survive this, so why would KSP count solar panel as part?

[Red Iron Crown]

Wait so if I use 80t fuel tank and put 300 solar panels on it physics engine will count that as 301 parts? That is very wrong, even 300 solar panels have very little impact on how 80t tank will fall, fly or whatever. And if 80t tank is going to hit something at 30+m/s I am sure solar panel won't survive this, so why would KSP count solar panel as part?

If the panels are OX-STATs the impact is minimal as they are physicsless.

[Nigeth]

If you want a simulation that at least approaches a behaviour like you would expect it in real life - let alone a semi-realistic one - then yes, KSP would have to count those as individual parts.

As far as a simulation is concerned those 300 solar panels:

- change the drag of the vessel and therefore change the aerodynamic behaviour

- change the drag of the vessel and therefore change the shock heating, aerodynamic heating and heat transfer/conduction behaviour of the vessel

- change the mass of the vessel and therefore change fuel consumption, TWR and astrodynamic behaviour of the vessel.

- change center of mass and center of lift

- probably don't change mass and drag evenly and therefore add additional force vectors to the vessel

- forces applied during flight could exceed the physical limits of the joints/connections between the panels and the tank or of the panels temselves. Panels could break of or get destroyed.

So yes, if you want a somewhat authentic behaviour those would have to be treated as individual parts and the physics model would need to be applied to all of them.

Unless they are OX-STAT panels because then they are physics-less

[Padishar]

As far as a simulation is concerned those 300 solar panels:

<snip>

Unless they are OX-STAT panels because then they are physics-less

They also add EC to the vessel on every frame which currently involves the code scanning through every part in the vessel to build a list of those parts that will receive the EC and then running through that list to actually add the resource to the part. This is done for every part that generates or consumes any resource, though the flow mode does affect the performance implications (STACK_PRIORITY_SEARCH is usually quicker for large ships than ALL_VESSEL or STAGE_PRIORITY). E.g. try sticking 72 fuel cells on your vessel and turning them on. Each fuel cell part consumes LF and O and generates EC, for three calls to scan the whole vessel for each fuel cell part on each frame. This has a serious impact on FPS...

[Darnok]

If you want a simulation that at least approaches a behaviour like you would expect it in real life - let alone a semi-realistic one - then yes, KSP would have to count those as individual parts.

As far as a simulation is concerned those 300 solar panels:

- change the drag of the vessel and therefore change the aerodynamic behaviour

- change the drag of the vessel and therefore change the shock heating, aerodynamic heating and heat transfer/conduction behaviour of the vessel

- change the mass of the vessel and therefore change fuel consumption, TWR and astrodynamic behaviour of the vessel.

- change center of mass and center of lift

- probably don't change mass and drag evenly and therefore add additional force vectors to the vessel

- forces applied during flight could exceed the physical limits of the joints/connections between the panels and the tank or of the panels temselves. Panels could break of or get destroyed.

So yes, if you want a somewhat authentic behaviour those would have to be treated as individual parts and the physics model would need to be applied to all of them.

Unless they are OX-STAT panels because then they are physics-less

Ok, I understand that, but my point is... is it really worth it to count 300 solar panels when they are attached to 80t vehicle?

IMO it should be dynamic solution (no idea if it is possible in unity) , if root part is very heavy and child parts are relatively light is it really worth to decrease performance and waste CPU on those parts?

If I connect two 80 tons tanks and put 300 different very small parts on each of those tanks, maybe it would be better from performance perspective to do not count those little parts?

[TheTom]

Are you joking? I understand there being a recalc event when vessels split or merge. But this list is static. Producers and consumers do not change every frame (though some may turn to producing 0). Programming bug. This is stuff that should not happen. Total overhead. How many rounds does physics do per second? Energy and resources could easily work with a slightly smaller frequency. And consumer/producer lists should be precalculated.

This is exactly the stuff I work on - I sometimes have to run 100.000 loops per second in our code. Heck, most of the code i write is faster = better because it emans we get more done with less computers. Abandoning processing as fast as possible, as well getting rid of garbage by not creating it is critical. The linked bug report would be a critical priority item in my world - there should be 0 garbage generated in scenarios like this.

Edited July 8, 2015 by TheTom

[Red Iron Crown]

That list isn't static, though. The solar panels have varying degrees of production based on solar distance and attitude, other parts have varying degrees of consumption (torque wheels vary greatly, for example). That's not to say that there isn't room for optimization, but it isn't as simple as it first appears.

[Nigeth]

They also add EC to the vessel on every frame which currently involves the code scanning through every part in the vessel to build a list of those parts that will receive the EC and then running through that list to actually add the resource to the part. This is done for every part that generates or consumes any resource, though the flow mode does affect the performance implications (STACK_PRIORITY_SEARCH is usually quicker for large ships than ALL_VESSEL or STAGE_PRIORITY). E.g. try sticking 72 fuel cells on your vessel and turning them on. Each fuel cell part consumes LF and O and generates EC, for three calls to scan the whole vessel for each fuel cell part on each frame. This has a serious impact on FPS...

My computer engineering sense is tingling and tells me that this might be a tad inefficient. BTW I didn't intend my list to be comprehensive or complete I just wanted to give a few examples.

- - - Updated - - -

That list isn't static, though. The solar panels have varying degrees of production based on solar distance and attitude, other parts have varying degrees of consumption (torque wheels vary greatly, for example). That's not to say that there isn't room for optimization, but it isn't as simple as it first appears.

I agree. You probably don't need to recalculate resource consumption and EC flow on every frame though.

[TheTom]

@RedIronCrown:

That list isn't static,

It totally IS static. A solar panel is a producer of electricity. Whether it produces them or not is irrelvant for this list. As long as it is there - even if inactive - it is in the list of producers. A simple flat allows a fast "skip" check in a tight loop (especially as this is not in the panel but in the subsystem in one list which means processor locality.

You also keep a counter of ACTIVE producers and consumers and can do some more optimizations. THe whole rtrick is not to search for "which part may provide electricity now" going through every single part of a rocket every frame

The list only changes then panels are added (docking) or removed (staging).

@Nigeth: And that is another part. I would dare saying that you can possibly run resources in 20 updates per second intervals with noone realizing it. If every part keeps a small buffer or asks for enough - the result differences should be miniscule

[Padishar]

Are you joking? I understand there being a recalc event when vessels split or merge. But this list is static. Producers and consumers do not change every frame (though some may turn to producing 0). Programming bug. This is stuff that should not happen. Total overhead. How many rounds does physics do per second? Energy and resources could easily work with a slightly smaller frequency. And consumer/producer lists should be precalculated.

This is exactly the stuff I work on - I sometimes have to run 100.000 loops per second in our code. Heck, most of the code i write is faster = better because it emans we get more done with less computers. Abandoning processing as fast as possible, as well getting rid of garbage by not creating it is critical. The linked bug report would be a critical priority item in my world - there should be 0 garbage generated in scenarios like this.

I assume this was in reply to me. No, unfortunately, I'm not joking. That bug report clearly shows the massive garbage thrash caused and the effect it has on FPS is extreme. Obviously it is a rather contrived example but going from easily sustaining 60fps to < 20fps is serious. In the case of EC (or any other ALL_VESSEL or STAGE_PRIORITY resource) the list of parts that is generated doesn't depend on which part the function is called on though it does depend on the resource, the flow mode being used for the resource and the flow direction (e.g. adding or removing resource). The list only changes when a part becomes empty or full (depending on the direction) or when parts are added to or removed from the vessel so it would be quite easy to cache the list for each combination of resource and flow direction and either modify the list directly when tanks empty/fill or mark the list as dirty when the vessel changes. STACK_PRIORITY_SEARCH is more complex as this generates a different list of parts depending on which part it is called on. However, again, for a particular part, the list only needs to change when a tank becomes empty or full so these lists could still be cached though it wouldn't improve things quite as much.

Eliminating (or at least greatly reducing) the garbage creation would be fairly simple and I hope they get around to it soon. The above list caching stuff is more complex and should be done as a separate task as a lot of care will be needed to ensure the lists are updated when they should be or some very odd bugs will occur.

That list isn't static, though. The solar panels have varying degrees of production based on solar distance and attitude, other parts have varying degrees of consumption (torque wheels vary greatly, for example). That's not to say that there isn't room for optimization, but it isn't as simple as it first appears.

Yes, the list(s) aren't static but it really wouldn't be difficult and would be much more efficient to update the list(s) directly by removing the part(s) that have become empty or full than rebuilding the list from scratch by scanning the entire vessel every frame.

[Red Iron Crown]

I think we're using different terms. The part list is static (outside of staging, docking and unplanned disassembly), the game engine runs through the whole list every frame and updates resources as it hits each part in the pass, no searching is done (aside from flow rules to determine where outputs go and from where inputs come). An argument could certainly be made that this doesn't need to be done every frame (especially for non-propellant resources), but the pass through the part list is happening anyway.

[TheTom]

Well, whatever is done is done in such a way to generate a tremendous amount of garbage. That said, also propellant can be accounted for less often Grab larger chunks, account for them in the engine (hey, the pipes have some of the stuff...). Same for everything else. But the garbage really has to go - optimally there should be 0 garbage generated during a normal frame calculation.

And whatever this is will not really be fixed fast - priority low as per website. I hope that is because they plan a rewrite here

Edited July 8, 2015 by TheTom

[Padishar]

I think we're using different terms. The part list is static (outside of staging, docking and unplanned disassembly), the game engine runs through the whole list every frame and updates resources as it hits each part in the pass, no searching is done (aside from flow rules to determine where outputs go and from where inputs come). An argument could certainly be made that this doesn't need to be done every frame (especially for non-propellant resources), but the pass through the part list is happening anyway.

You are misunderstanding. The loop through the part list you are describing doesn't actually happen. What happens is that each object derived from MonoBehaviour is looped through by Unity and has the Update/LateUpdate/FixedUpdate functions called (Unity makes several loops). Every PartModule (which is derived from MonoBehaviour) that wants to produce or consume resource calls one of the part.RequestResource functions to do it. This function always scans through all the parts of the vessel making this inherently O(n^2) at best. The point is that if one fuel cell has just added 0.023 ec to the vessel by building the list of batteries and other EC storage parts that have any space in them and then splitting the 0.023 between them all, then the next fuel cell on the ship shouldn't need to build the list again. If the first cell managed to fill up any of the parts then they would be removed from the cached list and, if the list is now empty, the scan would be done again (to cope correctly with STAGE_PRIORITY). It wouldn't be necessary to make it not happen every frame if it was sensibly cached. Besides, it tends to introduce all sorts of odd issues when you have things running at different frequencies (e.g. aliasing effects)...

[TheTom]

But ALiasing effects are not necesssarily wrong. See, does my computer stop the moment that my power fails? NO. I have some milliseconds time - there are capacitators in the power supply becasue small millisecond fluctuations are normal (and I am not talking batteries like in a USV - these capacitatos are also there to handle small micro fluctuations in the energy level that computers really do not like). Does my car stop the moment the tank is empty? NO The pump (in the engine) still sucks the pipes dry