对于一个必须只包含唯一项目但在99%的时间内包含0或1项的列表,开销是否比HashSet更好？

Question

我目前正在开展一个项目,我们有一系列活动.我们对事件进行的一项分析是查看特定类型的事件并检查它是否可能是由不久之前发生的另一事件(或在一个奇怪的情况下稍后发生)引起的.这些事件中的每一个只能通过单个事件来实现,但是一个事件可能是多个事件的因果事件.我们希望这种关联可以双向进行,这样,从任何特定的方法,您都可以直接进入导致它的事件,或者它引起的事件之一.基于此,我首先将以下属性添加到Event对象并添加功能:

protected Event causalEvent;
protected List<Event> effectedEvents;

经过一番思考后,我认为我们从不希望将相同的项目添加到effectedEvents列表中两次.在阅读了防止重复列表<T>条目的答案后,我选择了Hashset.

protected Event causalEvent;
protected HashSet<Event> effectedEvents;

一位同事和我讨论了我添加的代码,他指出使用一个HashSet可能会让人感到困惑,因为他倾向于看到HashSet并假设有大量的数据.在我们的例子中,由于算法中使用的规则,effectedEvents在大约90%的情况下将有0个项目,在9%中将有1个项目,在1%的时间内将有2个项目.我们几乎永远不会有超过2项,尽管有可能.我相信两个集合的查询成本是相同的.使用的内存量非常相似,因为两者都开始假设一个小容量(虽然,我会承认,这List使您能够在构造函数中设置该容量,同时HashSet只允许根据其内容减少值,"四舍五入到特定于实现的值").

因此,长期的问题是,HashSet对于那些不熟悉使用它以确保唯一性的人,使用除了可能的混淆之外是否有任何真正的惩罚？

Answer 1

进行分析在这个答案表明,你只看到性能上的优势HashSet在List,当你到5串,或20个对象(当然,结果会根据你在做什么).由于几乎在所有情况下你都会有0-2项,所以你最好的表现就是使用List.

我不担心那些不熟悉使用a HashSet以确保唯一性的人的困惑.这是a的主要用途之一HashSet.选择最适合工作的工具,如果你认为人们会感到困惑,那么简短的评论可以帮助你做到这一点.

此外,尽管使用性能最佳的编码策略是好的,但您也应该注意花费太多时间进行微观优化,这可能为时过早.除非你使用大量的这些对象,你可能不会注意到之间的差异List,并HashSet在此情况下.