[ENHANCEMENT] Improve caching of structural data

[ogauthe]

As title. Currently there is one LRU cache

const unitary_cache = LRU{
  Tuple{
    SectorFusionTree,SectorFusionTree,SectorFusionTree,SectorFusionTree,Tuple{Vararg{Int}}
  },
  Float64,
}(;
  maxsize=10000,  # TBD size
)

This can be cleaned up.

[lkdvos]

A small comment on the keytype: I think that in general for non-concrete containers, unless the range of types is small you are better off replacing that with LRU{Any,Float64}, since the compiler cannot do anything smart with the knowledge about the abstract types anyways, and the sysimage might already contain code for working with containers of Any, such that you reduce code size. (This is rather technical and probably won't matter too much, but it might reduce compile times in the future and is a minor comment to make)

On a separate note, I'm a bit surprised you put both input and output trees in the key. If I am not understanding this wrong, that means you have to store N^2 entries for each permutation (N being the number of tree pairs of a single tensor), while this object is generally really sparse. You could store a dictionary of output tree => coefficients for each input tree + permutation key, severely reducing the number of entries (and also reducing the loop you need in the actual permutation code from looping over all entries to only the non-zero ones)

[ogauthe]

Thnaks for the clue on Any.

Concerning your second point, this cache stores the overlap of the fusion trees. It is not the unitary matrix itself, which reuses the cache data. The cache is only written if the input and output tree pairs match, i.e. correspond to the same outer block.

[lkdvos]

Makes sense, thanks for clarifying!