wrap RawAuctionData in Arc for efficient sharing

[ashleychandy]

Description

Fixes a performance issue where RawAuctionData was fully cloned on every current_auction() call in the run loop. Wrapping it in Arc makes the clone operation a reference counter increment instead of a deep copy of all orders, prices, and metadata.

Changes

• Wrap RawAuctionData in Arc within the solvable orders cache
• Update current_auction() to return Arc<RawAuctionData> and use cheap Arc::clone()
• Update persistence methods to accept &Arc<RawAuctionData> and use .as_ref().clone() when cloning is necessary
• Clone auction data only when converting to domain::Auction or DTO (once per auction vs. every cache access)

[gemini-code-assist]

Code Review

This pull request introduces Arc wrapping for RawAuctionData to improve data sharing efficiency within the autopilot service. Feedback suggests avoiding the use of &Arc as a function parameter to reduce unnecessary indirection and simplify the API. Additionally, it was noted that deep clones of auction collections are still being performed in the run loop, and refactoring the domain::Auction struct to use Arc for its internal fields would better achieve the intended performance gains.

[gemini-code-assist]

These lines perform deep clones of the orders, prices, and surplus_capturing_jit_order_owners collections on every auction cycle. While this is necessary because domain::Auction expects owned data, it significantly limits the performance gains of wrapping RawAuctionData in an Arc. To fully achieve the goal of efficient sharing, consider refactoring the domain::Auction struct to use Arc for its collection fields, allowing these to be cheap pointer increments instead of deep copies.

[ashleychandy]

Hey @MartinquaXD, thanks for the input on the last PR. I’d like to learn the proper way to approach these kinds of optimizations going forward. Could you point me toward the usual steps/process you’d expect here, like how to benchmark it properly and validate that the change is actually meaningful?

[jmg-duarte]

Could you point me toward the usual steps/process you’d expect here, like how to benchmark it properly and validate that the change is actually meaningful?

Sadly, we need to measure this in production, meaning that you can't really provide the benchmarks out of the box.
For very obvious improvements, like the iteration reduction, we can merge them confidently that at least things won't get worse.

But in general, we need to measure them before and after, all that not before ensuring they're correct

[ashleychandy]

But in general, we need to measure them before and after, all that not before ensuring they're correct

Thanks @jmg-duarte , that clears things up. I'll make sure to frame future optimization PRs more carefully and justify claims properly.