Dictionary(StringComparer) 与 Dictionary并存储 key.ToUpper :您应该选择哪一个?

发布于 2024-08-30 07:52:24 字数 421 浏览 3 评论 0原文

免责声明:也许是微 YAGNI 优化,但听我说。

问题是实现一个不区分大小写的查找表。

  • 我的老方法:在填充字典时,在插入之前将键大写。当有人给你一个查找键时,将键大写。
  • 新方法(我今天了解到):Dictionary 接受 IComparer 实现,因此我可以传入 StringComparer.InvariantCultureIgnoreCase 。我认为它将委托给 String.Compare(x, y, SomeIgnoreCaseEnum)

新方法的优点是我不需要确保在完成查找的 n 个位置中的每个位置执行 .ToUpper()反对字典。

我的问题是哪一个更有效率?我想只是好奇......

更新:注意我不需要知道插入的原始密钥。此外,所使用的密钥与文化无关。

Disclaimer: Maybe be micro-YAGNI-optimizing but hear me out ..

The problem is to implement a case-insensitive lookup table.

  • My old-skool way: While populating the dictionary, upper-case the key before inserting. Upper-case the key when someone gives you a key to lookup.
  • The new way (I learned about it today): Dictionary takes in an IComparer implementation, so I could pass in StringComparer.InvariantCultureIgnoreCase. I think it would delegate to String.Compare(x, y, SomeIgnoreCaseEnum)

The new way has an advantage in that I don't need to ensure that a .ToUpper() is performed at each of the n places where a lookup is done against the dictionary .

My question is which one is more efficient ? Just curious I guess...

Update: Note I don't need to know the original key that was inserted. Also the keys that are used are culture agnostic.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

始于初秋 2024-09-06 07:52:24

大写可能会更有效,因为它可以进行序数比较......但我非常怀疑这对您来说是性能瓶颈。与以往一样,在根据性能进行代码更改之前进行分析。

最终,指定字符串比较:

  • 意味着您不需要如此小心地使用字典
  • 意味着原始大小写保留在密钥中,这在某些情况下可以帮助诊断
  • 明确说明您想要如何使用密钥待处理。您最终只需在创建时声明一次 - 在我看来,这会导致代码更清晰。

It's possible that upper-casing would be more efficient, as it could then do an ordinal comparison... but I very much doubt that this is a performance bottleneck for you. As ever, profile before you commit to a code change on the basis of performance.

Ultimately, specifying the string comparison:

  • Means you don't need to be as careful about how you use the dictionary
  • Means the original casing is maintained in the key, which can help diagnostically in some cases
  • Explicitly says up-front how you want the keys to be handled. You end up stating it just once, at the point of creation - which leads to clearer code IMO.
蘑菇王子 2024-09-06 07:52:24

我不知道性能如何,但我更喜欢 StringComparer 选项。使用 ToUpper,您会丢失信息(原始大小写)。确实,你可能不需要它,但有一天你可能不需要它,并且感觉不需要再做任何工作来保存它(因此不受 YAGNI 原则的影响)。

有一天,我也会忘记给 ToUpper 打电话,陷入痛苦的世界。但我的单元测试当然会拯救我。

I don't know about the performance but I prefer the StringComparer option. With ToUpper you lose information (the original casing). True you might not need it, but one day you might and it doesn't feel like any more work to keep it (thus safe from the YAGNI principle).

I would also one day forget to call ToUpper and be in a world of hurt. But my unit tests would save me of course.

愚人国度 2024-09-06 07:52:24

我会接受 Oded 的“Go profile!”评论:)这是一个显而易见的建议。

根据我的测试(源代码此处

1M包含键查找,

  • ToUpper 方法:1123 毫秒
  • 字典(OrdinalIgnoreCaseComparer)
    :971 毫秒

我发现带有注入比较器选项的字典可以执行更好且更少的麻烦。所以我不再需要 ToUpper() 了。

I'd have accepted Oded's 'Go profile!' comment :) which was a Master-of-the-obvious suggestion.

From my test (source code here)

For 1M ContainsKey lookups,

  • ToUpper approach : 1123 msecs
  • Dictionary(OrdinalIgnoreCaseComparer)
    : 971 msecs

I find Dictionary with an injected Comparer option to perform better and less hassle. So no more ToUpper() for me.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文