Prune orders might be compute inefficient

[Henry-E]

In the prune orders function, there's a remove all function that iterates over both the bid and ask queues to find orders owned by a particular open orders account. The issue with this is that if you have an orderbook with a lot of orders the function can run out compute units. While the solution to this in the function is to lower the limit parameter, I was wondering about the design of the function. Is there a reason why it's necessary to iterate over the bid and ask queues to get the order ids when the open orders account already stores the order ids?

serum-dex/dex/src/matching.rs

Lines 146 to 168 in 5b43fe1

	// Removes all orders belonging to the given open orders account.
	pub fn remove_all(
	&mut self,
	open_orders: [u64; 4],
	mut limit: u16,
	) -> DexResult<(Vec<LeafNode>, Vec<LeafNode>)> {
	let asks_matching_open_orders = self
	.asks
	.find_by(&mut limit, |order| order.owner().eq(&open_orders));
	let bids_matching_open_orders = self
	.bids
	.find_by(&mut limit, |order| order.owner().eq(&open_orders));
	let bids_removed: Vec<LeafNode> = bids_matching_open_orders
	.iter()
	.filter_map(|order_to_remove| self.bids.remove_by_key(*order_to_remove))
	.collect();
	let asks_removed: Vec<LeafNode> = asks_matching_open_orders
	.iter()
	.filter_map(|order_to_remove| self.asks.remove_by_key(*order_to_remove))
	.collect();
	Ok((bids_removed, asks_removed))
	}
	}

vs. how just passing the order id to remove the leaf node, like in the cancel order function?

serum-dex/dex/src/matching.rs

Lines 931 to 942 in 5b43fe1

	pub(crate) fn cancel_order_v2(
	&mut self,
	side: Side,
	open_orders_address: [u64; 4],
	open_orders: &mut OpenOrders,
	order_id: u128,
	event_q: &mut EventQueue,
	) -> DexResult {
	let leaf_node = self
	.orders_mut(side)
	.remove_by_key(order_id)
	.ok_or(DexErrorCode::OrderNotFound)?;