rusandris / StateTransitionNetworks.jl

Toolkit for dynamics on state transition networks
2 stars 0 forks source link

Speedup needed in `higher_order_symbolics!` #18

Open rusandris opened 7 months ago

rusandris commented 7 months ago

When dealing with higher order states, a significant amount of time is spent on transforming to states of higher order.

using DynamicalSystems,StateTransitionNetworks
ds = Systems.logistic()
orbit,t = trajectory(ds,10^8;Ttr=1000)
sts = timeseries_to_grid(orbit,20)

@time higher_order_symbolics!(sts,10)
 13.534721 seconds (106.11 k allocations: 7.337 MiB, 1.12% compilation time)

We can speed it up by remapping the original symbols before doing anything else (even though this means we are going to loop through symbolic_timeseries twice) :

 @time higher_order_symbolics!(sts,10)
  6.721250 seconds (87.98 k allocations: 6.084 MiB, 2.22% compilation time))

See fix here ba0db6c

rusandris commented 7 months ago

Readibility could also be improved by wrapping the loops into separate functions

rusandris commented 7 months ago

TODO: add docstring, and don't forget to mention that the last order-1 elements aren't converted to higher order states

rusandris commented 7 months ago

If we allow calculate_transition_matrix to do the remapping in-place beforehand, it can be omitted entirely from higher_order_symbolics!.

And calling higher_order_state can be avoided since loops can be merged into one. See this here 5f279df422d438e7b5e72bbb9a51905a512b411e , also 28570fa26973dcbda88e8f76c894f6dd8b9089be

With all these we get even better performance:

@time higher_order_symbolics!(sts,10)
  4.801914 seconds (26.55 k allocations: 1.884 MiB, 1.25% compilation time)
rusandris commented 7 months ago

Option needed in case one needs remapping (calculate_transition_matrix) wasn't run before resorting to higher order states