Increased Orekit pipeline execution time

Dear all,

I’ve noticed that, over time, the execution time of the Orekit pipeline gets considerably longer, especially for the verify job.

Here’s a sample of the execution time of the verify job over time on my runner:

Date Execution time Examples
apr. 2022 ~13 min. 1, 2, 3
jan. 2023 ~20 min. 4, 5, 6
apr. 2023 ~21 min. 7, 8, 9
jul. 2023 ~26 min. 10, 11, 12
now ~27 min. 13, 14, 15

In April 2022, the complete pipeline execution time on my runner was less than 15 minutes. Today, it’s over 30 minutes.

This increase in pipeline execution time may be logical (you’ve added a lot of functions and the necessary unit tests to check that they work). But it may also be symptomatic of a degradation in Orekit’s performance. In either case, I wanted to draw your attention to this point, as we all know that a good CI/CD pipeline should provide fast feedback to developers. It may be wise to think about the relevance of the unit tests performed, their possible redundancy and so on.

Over the same period, the RAM consumed by the Orekit pipeline increased from 10 to 14 GB.

The problem could also be exogenous, linked to a change in the environment. In this case, I haven’t changed my runner’s hardware configuration or installed any new software since April 2022. The average load on this machine when it’s not running any Orekit pipelines hasn’t changed over this period of time. The only notable change on this machine is a BIOS change I made a few days ago.

Further proof that the evolution is indeed attributable to the pipeline and not to its environment: on the other runner used by this project, between April 2022 and today, the average pipeline execution time has risen from 30 to 45 minutes.


Thanks Sébastien for these interesting numbers. I guess over the pass year or so the next major release has been in the making, with its load of new features (so by definition more code to cover) but also of refactoring linked to changed APIs, which may be less performant from a computational point of view. So thank you for this reminder of not overlooking that aspect. As a matter of fact @MaximeJ very recently pointed out a performance regression compared to version 11.X of Orekit, namely linked to SRP inclusion within OD. I take this opportunity to reach out to users of the develop branch out there (if any :sweat_smile:), please let us know about any negative outcome of the commits since 11.3.3 that you have experienced, by posting on this forum or directly opening an issue if you’re confident enough in the root cause.