- 主题:list有什么实现或者替代么?
发现标准库中的list,没办法直接删除中间的一个结点。而且rust中list本身实现还是挺复杂的。不知道有没有rust的方式来解决我这样的问题。
有个hash表。数据来的时候我就找到对应的node(或者插入新node),更新时间。需要定期去把hash中的很久没有更新的node删除。避免被撑爆。
我的办法就是。在node插入hash的同时,在一个list中记录这个node的引用。每当这个node更新了时间,就把node从list当前位置摘下来移动到list尾部。这样,这个list的头部就会是最老的那些node。然后没几秒钟去遍历一下list头部。如果过期了。就删除。
这样可以避免定期遍历整个hash,不会卡顿。
针对上面的办法。却发现rust标准库中的链表不支持删除任意的结点。请问各位有什么其他链表实现推荐么?再或者,发现rust貌似不推荐使用list,那么这种需求rust的解决方式是什么样的?
--
FROM 117.133.52.*
你这个需求叫 LRU cache, rust 有个crate叫 HashLRU,你可以直接用。
【 在 chunhui 的大作中提到: 】
: 发现标准库中的list,没办法直接删除中间的一个结点。而且rust中list本身实现还是挺复杂的。不知道有没有rust的方式来解决我这样的问题。
: 有个hash表。数据来的时候我就找到对应的node(或者插入新node),更新时间。需要定期去把hash中的很久没有更新的node删除。避免被撑爆。
: 我的办法就是。在node插入hash的同时,在一个list中记录这个node的引用。每当这个node更新了时间,就把node从list当前位置摘下来移动到list尾部。这样,这个list的头部就会是最老的那些node。然后没几秒钟去遍历一下list头部。如果过期了。就删除。
: ...................
--
FROM 114.92.200.*
如果不是完美契合你的需求,需要修改,你可以看它的代码
【 在 RunningOn 的大作中提到: 】
: 你这个需求叫 LRU cache, rust 有个crate叫 HashLRU,你可以直接用。
--
FROM 114.92.200.*
我这个不是lru。我这个是反lru....和cache正相反,hash并不能满足要求。否则我就直接用文中提到的hash了。
【 在 RunningOn 的大作中提到: 】
: 你这个需求叫 LRU cache, rust 有个crate叫 HashLRU,你可以直接用。
--
FROM 117.133.52.*
我其实就是需要一个可以随意在中间删除结点的链表。但是标准库里的不行。自己实现看样子有点麻烦。实在不行就用 unsafe prt这种方式实现了。
【 在 RunningOn 的大作中提到: 】
: 如果不是完美契合你的需求,需要修改,你可以看它的代码
--
FROM 117.133.52.*
你这就是LRU啊。
无非是你的需求是删除一段时间内没有用过的数据,lruhash实现的是规定了最大数据量,本质上是一样的。旧数据是在队头还是队尾都一样的,队尾也是可以直接访问。
【 在 chunhui 的大作中提到: 】
: 我这个不是lru。我这个是反lru....和cache正相反,hash并不能满足要求。否则我就直接用文中提到的hash了。
--
FROM 114.92.200.*
你刚才说的是:
https://gitlab.com/liberecofr/hashlru 这个?
我看它里面也用到了hash。或许我可以直接用它这个hash替代我前面说的自己的hash。直接用这个lur就行了。我连自己的hash也省了。还没来得及细看它的行为是不是我要的。
【 在 RunningOn 的大作中提到: 】
: 你这就是LRU啊。
: 无非是你的需求是删除一段时间内没有用过的数据,lruhash实现的是规定了最大数据量,本质上是一样的。旧数据是在队头还是队尾都一样的,队尾也是可以直接访问。
--
FROM 117.133.52.*
是啊。这难点是LRU,不是Hash,Hash现成的方案很多。
【 在 chunhui 的大作中提到: 】
: 你刚才说的是:
https://gitlab.com/liberecofr/hashlru 这个?
: 我看它里面也用到了hash。或许我可以直接用它这个hash替代我前面说的自己的hash。直接用这个lur就行了。我连自己的hash也省了。还没来得及细看它的行为是不是我要的。
--
FROM 114.92.200.*
这个lru,听起来挺费操作的,每一个插入都要动态维护,但既然有这个库,是否意味着这种每次动态维护的策略,毫无疑问优于每次混乱插入、定期维护一次的策略?
【 在 RunningOn 的大作中提到: 】
: 是啊。这难点是LRU,不是Hash,Hash现成的方案很多。 ...
--
FROM 221.218.141.*
得不出这个结论吧。
LRU的存在,不是因为他比什么方法更优,而是因为LRU (least recently used,淘汰最久不用的数据)是实实在在的需求,哪怕实现起来费劲或性能不好,也得实现一个。
【 在 AlphaO 的大作中提到: 】
: 这个lru,听起来挺费操作的,每一个插入都要动态维护,但既然有这个库,是否意味着这种每次动态维护的策略,毫无疑问优于每次混乱插入、定期维护一次的策略?
--
修改:RunningOn FROM 114.92.200.*
FROM 114.92.200.*