Did you succeed in porting the code? It would not be easy according to my experience with PRIMA. I would be happy to learn if you have a GitHub repo of it. Thanks.
Yes, at least the parts that my research group used regularly. I ported them to Rust, though, not modern Fortran. They're also pretty specific to computational chemistry, rather than general packages like PRIMA, but I'll link them here in case you're curious anyway. I was also still learning Rust and followed the original Fortran API and naming scheme where possible, so this code could use a refactor too! But at least there are no gotos.
https://github.com/ntBre/anpass - ordinary least squares fitting https://github.com/ntBre/intder - internal coordinate transformations https://github.com/ntBre/spectro - vibrational perturbation theory
PRIMA looks very interesting, by the way. I may see if I can get some use out of it in my research!
Feels like you've just read grugbrain.dev and decided to shoot your golden tips at everybody without actually trying to understand the situation.
Anyway, there's one good point here:
> why is your allocator in this path, then?
Because those prices change 24/7/365, million times a day, and so refreshing happens pretty much all the time in the background, eating CPU time. What's more, calculating prices is much more complicated than a hashmap lookup - hotels can have dynamic number of discounts, taxes etc., and they can't all be precomputed (too many combinations).
You know, not all complexity is made up, a little trust in others won't hurt.
On second glance, I guess this is what you're getting at with the ArcSwap comment in the post. It sounds like you really do want to reallocate the whole State and atomically swap it with the previous state, which would make reusing the prices Vec impossible, at least without keeping around two States and swapping between them.
Anyway, tone aside, I still think the comment had validity in a general optimization sense, even if not in this specific case.