我看到一篇关于 perl 脚本性能的文章。
他们提到的一件事是使用哈希引用而不是每次都直接访问哈希。
引用哈希而不是直接访问有什么好处？
我的脚本从服务器名称列表中读取，如果有人需要这么多机器，理论上可能多达 100 台机器。所以我能给我的剧本带来的任何提升都会很棒。
问问题
1272 次
4 回答
8
我不认为 over 有什么$hashref->{"foo"}优势$hash{"foo"}。将哈希引用而不是完整哈希传递给子例程可能有一个小优势，但这就是我能想到的。我同意 Rafe 的评论，即 100 个项目的散列不太可能给您带来性能问题。除非您知道您有与哈希表访问相关的性能问题，否则不要为此烦恼。
“优化已调试的程序比调试已优化的程序更容易。”
于 2011-04-17T08:17:17.833 回答
2
我之前评论过，100 对于哈希来说很小。我将用更一般的陈述来限定这一点：
除非有问题，否则不要担心。您的脚本运行缓慢吗？如果没有，那么不要修复没有损坏的东西。过早的优化不利于可读性，并且通常会导致错误。这是 2004 年的一个更大的问题，当时我认为您正在阅读的文章是写的。但是今天，RAM 很便宜。
也就是说，使用引用网络比通过值传递更好的性能的原因是，当您将哈希作为参数传递给子时，通常必须复制它，这会使用更多内存。这只是在以下情况下需要进行的优化。）您将大散列传递给函数很多，并且 b.）这会导致您使用过多的内存。
于 2011-04-17T08:20:28.567 回答
0
好吧，正如 Rafe 已经提到的，具有 100 个元素的散列并不是很大。有人可能会争辩说，与使用普通散列相比，使用散列引用并没有给你带来太多优势——但它也没有给你带来特别的劣势（至少我从来没有遇到过这样的劣势）。因此，过早的优化并不像人们想象的那么糟糕。
如果您的脚本运行速度太慢，那么您可能需要使用分析器来找出您浪费时间的地方。
于 2011-04-17T08:26:01.100 回答
0
抱歉，如果那篇文章是这样说的，那就错了。取消引用然后访问散列元素不可能比仅访问散列元素花费更少的时间。
>perl -MO=Concise,-exec -e"$x = $h{x}"
...
3 <#> gv[*h] s
4 <1> rv2hv sKR/1
5 <$> const[PV "x"] s/BARE
6 <2> helem sK/2
...
>perl -MO=Concise,-exec -e"$x = $h->{x}"
...
3 <#> gv[*h] s
4 <1> rv2sv sKM/DREFHV,1 <---
5 <1> rv2hv[t3] sKR/1
6 <$> const[PV "x"] s/BARE
7 <2> helem sK/2
...
也就是说，deref 所花费的额外时间应该是微不足道的。
于 2011-04-18T01:49:15.800 回答