_process(delta) or _fixed_process(delta) for intensive computations?

Question

Between _process(delta) and _fixed_process(delta), which virtual function should be used to run intensive computations that happen as fast as possible, to save CPU and to keep the FPS high?

An example would be, regenerating the health of a player continuously.

# This?
func _process(delta):
    health = min(health + 5*delta, 100)

# Or this?
func _fixed_process(delta):
    health = min(health + 5*delta, 100)

Which one should be preferred for performance?

Comments

Related: http://godotengine.org/qa/96/efficient-spread-bigger-calculations-over-multiple-frames

---

As comment because i am not absolutely sure i didn't messed something up.
In my experience if you have a lot to do (even if it is physics related) fixedprocess leads to way worse stutters and FPS drops as process does.
Even if the docs say _fixedprocess and integrateforces are the only way to interact with the Physics engine without blocking, everytime i did this the result was worse as if i did it in _process.

Answer 1

If health regeneration does not involve physics use _process(delta).

The _fixed_process(delta) should be used when physics has to be called every frame.

Answer 2

fixed_process is constraint to your physic_fps which are default at 60fps.
This means that _fixed_process is called every 1/60 seconds => 0.016667s.
_process instead is called every rendered frame. This means that it's delta depends on the complexity of your scene and the speed of your computer. You should always try to use the _process function and correct calculations by using the delta value (as you did in your example). Only if you really need your calculation to be parallel to the physic than you use _fixed_process(delta).

Answer 3

Just my 2 cents.

I would usually follow this procedure when picking between _process and _fixed_process:

• Is the logic concerning movement of a RigidBody? Move to _integrate_forces or (better not) _fixed_process.
• Is the logic concerning physics or direct space raycasts? Move it to _fixed_process.
• Is the logic doing something that affects only the gameplay business logic? Move it to _fixed_process. Because:
  
  
  • _processis called before rasterizing the next frame, which means it is FPS-dependent.
  • _fixed_process is linked to the physics thread, which means that all the logic would execute just as often as object are moved.
  • If the calculation is taking too long in _fixed_process it would drop the physics FPS, while the GUI would be just as responsive.
    
    
    • That's actually a bonus -- If it lagged the screen FPS instead, it would let objects that are affected by that logic fall through, die (because of late regeneration), etc.
• Is the logic only about drawing and showing stuff? Move it to _draw or _process as required.
  
  
  • This type of logic would never change values that are used by gameplay/physics logic, unless it is in change of user inputs, etc.
• If none of the above rules matches, split the logic in parts, and try again.
  
  
  • E.g. You can split health regeneration + health bar update between _fixed_process and _process.