There's another big optimization potential to speed up the generation of FK-tables. Currently, I believe, pineko works the following way (correct me if I'm wrong):

1. we store flavour-basis to flavour-basis EKOs for all Q2 slices, but always for the standard 50 x-node points. The biggest EKO that we have, ATLAS_1JET_8TEV_R06, is 2.4 GB.
2. Next, we reinterpolate the EKO to match the x-grid points actually used in the grid. For ATLAS_1JET_8TEV_R06 this blows up the size of the EKO to 22 GB.
3. Finally, we rotate the EKO, such that the resulting FK-tables are in the evolution basis. This further increases the size, resulting in whopping 45 GB.

But thanks to some developments on PineAPPL's side, we can now perform a rotation at the level of grids (and therefore also FK-tables). So I suggest that

• we perform the evolution using the unrotated EKOs, which has the advantage that the EKOs are much smaller, and finally
• rotate the evolved FK-tables from the flavour-basis to the evolution basis.

The evolution in the flavour basis is much faster, it's roughly the quotient of the size of the EKOs. For ATLAS_1JET_8TEV_R06 it's roughly twice as fast (45 GB / 22 GB). With the added benefit that we need less disk space, of course.

Practically speaking, the changes on pineko's side should be minimal. We probably have to delete the following lines:

and instead add the rotation after the evolution: