Decreased computation speed of EventDetector in Orekit 12.0

Dear all,

I have a question about EventDetector. I am writing a program to find the time of event occurrence from a given ephemeris. The program itself is working fine, but when I updated orekit to the latest version, the calculation speed slowed down significantly.

The code executed and its execution time are shown below. The event detection results were the same, but I don’t know why the execution times are so different. Does anyone know the cause?

Thank you,

// Given ephemeris
// Data for one week at 10 second intervals, so the list size is 60480
List<SpacecraftState> states = ...
GeodeticPoint station = ...

Frame itrf = FramesFactory.getITRF(IERSConventions.IERS_2010, true);
OneAxisEllipsoid wgs84 = ReferenceEllipsoid.getWgs84(itrf);
TopocentricFrame topo = new TopocentricFrame(wgs84, station, "station");

ElevationDetector detector = new ElevationDetector(topo)
        .withRefraction(new EarthStandardAtmosphereRefraction())
        .withHandler(new RecordAndContinue<EventDetector>());

Ephemeris ephemeris = new Ephemeris(states, 4);
ephemeris.propagate(ephemeris.getMinDate(), ephemeris.getMaxDate());

// Execution time [ms]:
//    647 (ver.11.3.3)
// 247621 (ver.12.0)

This is a huge performance drop!
What is strange is that many efforts to improve performance have been put in version 12.0, so we may have made an error somewhere.
Could you try to identify where the code spends most of its time now, using some monitoring tool lake yourkit or visualvm?

Hi there,

About the detector itself, the use of brand new getPosition should speed up the code w.r.t. 11.3.3, while getTrackingCoordinates should slow it down somewhat. So overall the performance there should be more or less stable. Thus I suspect that the problem lies somewhere else, either the event mechanism within the propagator or the construction/evaluation of the Ephemeris model.
Some profiling like Luc suggested would be idea. Otherwise at least some more details on the timing, maybe in between calls in your script.


Hi there,

I’m working on it to see if it’s not related to the introduced changes in how interpolation is done.


Okay so i managed to reproduce the issue. On my end i get the following results:

11.3.3 : 800ms
12.0 (without event detector) : 630 ms
12.0 (with event detector) : 66549 ms

I’ll need to use yourkit at work to be able to investigate this issue properly. I’ll post any update i have in this thread.

See the attached code to reproduce the issue (12.0 version). (3.5 KB)


UPDATE: It looks like it is caused by the presence of RecordAndContinue(). When removing it i get a computation time of 1500 ms which is still a regression but already much better.

UPDATE 2 : Found the main cause of this issue : when Ephemeris interpolates some spacecraftstate, it gives the whole sample to the spacecraftstate interpolator which then create a cache with the whole sample. So for each interpolation, we have to chronologically sort the 60480 states when we will only use 4 states which is not really optimal. I have tested a solution which reduce the computation time to 1300 ms on my computer. I believe this is reasonable now that everything is thread safe. I’m opening an issue.

Hello everyone,

I have opened a merge request regarding this issue.



Thank you everyone.
I understand that this will be fixed in the next release version.

Hi there,

Yes this will be fixed in an upcoming patch release.
Thank you for reporting it, much appreciated