# Performance¶

There are multiple different parts in **dynasor** that can be computationally expensive, and depending on the use case different parts of the code can become performance limiting.
The most time-consuming part of the dynamic structure factor calculations is usually the calculation of the Fourier transformed densities.
This part is implemented in numba, and is significantly accelerated by parallelization.
See below for run times of typical use cases.

Here, we try to provide some rough estimates for how long various types of calculations may take.

If trajectory reading and other overheads are disregarded and the incoherent part is not evaluated (`calculate_incoherent=False`

), calculations should scale as `N_qpts * N_atoms * max_frames`

.
Here `N_qpts`

and `N_atoms`

refer to the number of \(\boldsymbol{q}\)-points and atoms respectively.
Correlating the density between different frames in the window is often very fast and thus simulations often do not scale with `time_window`

.

If the incoherent part (`calculate_incoherent=True`

) is evaluated calculations will typically scale as `N_qpts * N_atoms * max_frames * time_window`

.
The **dynasor** calculations will typically become slower when calculating the incoherent intermediate scattering function.

## Parallelization¶

Parallelization is done both over \(\boldsymbol{q}\)-points (`N_qpts`

) when calculating the densities, and over time lags `time_window`

in the dynamic correlation functions.
By default the calculations will be parallelized over all available cores.

## Typical use cases¶

Here we will consider a few typical use-cases in order to provide a rough estimate for how long typical calculations may take, and how calculations may scale with number of available cores.

### Few \(\boldsymbol{q}\)-points¶

Below are some time estimates for a three component system of about 40,000 atoms and with a trajectory containing 10,000 snapshots. Here, only 5 high-symmetry \(\boldsymbol{q}\)-points are used as is typical when analyzing solids. The time window is set to 1000. Note that reading the trajectory (xyz format) accounts for a large part of the total computational time.

### Many thousands of \(\boldsymbol{q}\)-points¶

Below are some time estimates for a three component system of about 10,000 atoms and with a trajectory containing 10,000 snapshots. Here, we consider 1000 \(\boldsymbol{q}\)-points and conduct a spherical averge over \(\boldsymbol{q}\)-points. The time window is set to 400.

## Trajectory reading¶

The time spent on trajectory reading can be significant for the plain text based formats (e.g., xyz and lammps-dump). Therefore, if possible, we recommend using the binary formats if performance is essential and trajectory reading is a computational bottleneck.

The internal `extxyz`

-reader is multithreaded with decent scaling.
In the example only one core was used.