rust - 在Rust中的HashMap键上的工程(: Using reference (borrow?)上

Question

我正在使用一种搜索算法(BFS/DFS)来搜索游戏状态树。
我已经用C编写了东西，但是我想知道Rust是否会更快，而且由于我一直想学习Rust，所以我想尝试一下。
我正在尝试将其优化到过度工程化的程度(我喜欢，让我成为吧)，我已经在C中进行了优化，我认为这很酷，但是我不知道该怎么做(/if有可能)在Rust中。
我的算法概述如下:

Add the start state to a queue, and make a hashmap [State -> Previous State, Action]
// I use this hashmap to find the way back later, and to check if I have been in a state before.

Take a state S0 from the queue:
   for all possible actions, calculate next state S1:
      if S1 is already a key in the hashmap, continue
      and add [ S1 -> S0, action taken ] to the hashmap
      add S1 to the queue,
   ...
   // some other stuff here to check when to stop

我在C语言中所做的一种优化是:不是将状态结构数据复制到队列中，而是将指向哈希表中相同数据的指针(因为无论如何我都将其添加到哈希表中)复制到队列中，这种方式我不必复制状态数据，但队列仅包含指向哈希图中相同数据的指针。
这在C语言中很容易实现，因为我有自己的hashmap实现，因此很容易使函数返回指向hashmap中正确数据的指针。
在Rust中，我现在有这个:

// Add all possible moves to be searched through later
for m in possible_moves.iter() {
    if let Some(new_state) = popped.do_move(m) { // popped is S0 from my algorithm outline
        if backmap.contains_key(&new_state) { continue; }
        queue.push_back(new_state);
        backmap.insert(new_state, Wayback {
        prev_state: popped, did_move: m });
    }
}

但这意味着将new_state数据复制到队列和哈希图中。
我想知道是否有一种不像我的C版本那样在Rust中不复制此数据的方法(或其他方法)。
我想要这种优化，因为我喜欢它的优化感觉，但是在Rust的情况下，因为现在此副本意味着我在所有结构之上都具有 #[derive(Clone, Copy)]，如果没有办法做的话，这不是很好的imo。我过度设计的优化，但是有一种方法不必衍生就可以复制和克隆我仍然想知道的特征。
非常感谢您的帮助!
P.S.我知道这不是您的常规代码问题，从我的解释中可能还不清楚，因此，如果对我的意思有任何疑问，我将尽快回答。

Answer 1

I would like this optimization because I just like the optimized feeling of it, but in Rust's case also because right now this copy means that I have #[derive(Clone, Copy)] above all my structs, which is just not nice imo

根据结构的大小，这实际上有关系吗？ Copy只是 memcpy。

if there is not a way to do my over-engineered optimization, but there is a way to not have to derive to copy and clone traits I would still like to know.

这里的问题是Rust希望每个数据都有一个明确的静态所有者，但是在您的算法中不存在:该状态由 map 和队列“拥有”。 “共享”所有权不清楚的方法是使用 Rc，但这会转化为堆分配(如果不是原子的，则refcount流量实际上并不重要)，如果 state，这可能是一种悲观