Improve performance with mutating functions and Static arrays

[AlexS12]

Current situation
Most of the functions are non-mutating and use Base.Array

Objective
Although it performance is not a problem yet. Code would execute much faster using mutating functions to avoid reallocation and static arrays (https://juliaarrays.github.io/StaticArrays.jl/latest/pages/quickstart/)

Solution proposal

• Implement some benchmarks on the current situation. Is there anything in julia like pytest benchmarks? (https://pytest-benchmark.readthedocs.io/en/stable/
  9
• Try to find the current bottle necks with a profiler (https://docs.julialang.org/en/v1/manual/profile/) (https://mitmath.github.io/18337/lecture18/code_profiling)
• Decide what is easier to implement first: mutating functions / StaticArray
• Extra protect with tests functions to be refactored
• Run benchmarks & profiler again

[AlexS12]

Another interesting link: https://tutorials.juliadiffeq.org/html/introduction/03-optimizing_diffeq_code.html

[zsunberg]

I vote VERY STRONGLY for NOT MUTATING IN PLACE and focusing on using StaticArrays (or even allowing any AbstractVector or even any type to represent states, etc.)! :)

In my experience, this has two advantages:

1. As in the diffeq blog post above, for small systems (and I think most aircraft will have ~12-20 state variables) this is even faster than mutating in place.
2. It is MUCH easier to reason about how the code behaves. If you use immutable types you can save them in a trajectory or give them to another user without making copies or worrying about them being mutated in the wrong place.

If I use this package, I will need it to have the absolute highest performance possible because I will be doing online MPC and optimization-based planning, so I think it is well worth thinking about this now.

[AlexS12]

Absolutely agree that just using static arrays would provide a huge benefit and would keep things simpler than using inplace mutations.

I discovered static arrays some time ago, but decided to complete "all the functionalities" before making the optimizations, so I could have some nice benchmarks afterwards. The propagator will be finished soon. I think, once I have a couple of examples of the whole machinery working will be a good moment to benchmark and optimize.

If I use this package, I will need it to have the absolute highest performance possible because I will be doing online MPC and optimization-based planning, so I think it is well worth thinking about this now.

Sounds great!! 😲 I had some time on your webpage and, certainly, seeing this project working for some of your research work would be awesome. After all, my intention is to create a comfortable aircraft simulation framework which could be used to experiment with systems modelling, numerical investigations, parameter identification, control, optimization... I know, it's a pretty ambitious goal, but I am confident that starting with the basic features will attract a small community that will help to focus on more concrete goals.

[zsunberg]

Cool!

I just though of another reason to focus on a more functional/immutable paradigm: it makes auto-differentiation much easier.

my intention is to create a comfortable aircraft simulation framework which could be used to experiment with systems modelling, numerical investigations, parameter identification, control, optimization... I know, it's a pretty ambitious goal, but I am confident that starting with the basic features will attract a small community that will help to focus on more concrete goals.

I think this is a great goal! I am happy to be an external voice in discussions to help make the package easier for others to adopt!