Not sure why all the hostility here - you haven't seen the code, know nothing about the domain and yet you're certain that our performance requirements are false and that "code base got sacrificed" (apparently by adding two lines of rather self-explanatory code?)
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.
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.