perl スクリプトのパフォーマンスに関する記事を見ました。
彼らが言及したことの 1 つは、毎回ハッシュに直接アクセスする代わりに、ハッシュ参照を使用することです。
直接アクセスする代わりにハッシュを参照すると、どのようなメリットがありますか?
私のスクリプトは、サーバー名のリストから読み取ります。理論的には、誰かがその数を必要とする場合、100 台ものマシンになる可能性があります。したがって、スクリプトを後押しすることができれば、それは素晴らしいことです。
perl スクリプトのパフォーマンスに関する記事を見ました。
彼らが言及したことの 1 つは、毎回ハッシュに直接アクセスする代わりに、ハッシュ参照を使用することです。
直接アクセスする代わりにハッシュを参照すると、どのようなメリットがありますか?
私のスクリプトは、サーバー名のリストから読み取ります。理論的には、誰かがその数を必要とする場合、100 台ものマシンになる可能性があります。したがって、スクリプトを後押しすることができれば、それは素晴らしいことです。
$hashref->{"foo"}
以上のメリットはあまりないと思います$hash{"foo"}
。サブルーチンに完全なハッシュの代わりにハッシュ参照を渡すことにはおそらく小さな利点がありますが、それは私が考えることができるすべてです。いずれにしても、100 個のアイテムのハッシュがパフォーマンスの問題を引き起こす可能性は低いという Rafe のコメントに同意します。ハッシュ テーブルへのアクセスに関連するパフォーマンスの問題があることがわかっている場合を除き、これを気にしないでください。
「最適化されたプログラムをデバッグするよりも、デバッグされたプログラムを最適化する方が簡単です。」
以前、100 はハッシュとしては小さいとコメントしました。より一般的なステートメントでこれを修飾します。
問題がなければ気にしないでください。スクリプトの実行が遅いですか? そうでない場合は、壊れていないものを修正しないでください。時期尚早の最適化は可読性に悪影響を及ぼし、多くの場合バグにつながる可能性があります。これは、あなたが読んでいると思われる記事が書かれた 2004 年には、より大きな問題でした。しかし、今日、RAM は安価です。
とは言うものの、参照を使用すると値渡しよりもパフォーマンスが向上する理由は、ハッシュを引数としてサブルーチンに渡す場合、通常はコピーする必要があり、より多くのメモリを使用するからです。これは、a.) 関数に大きなハッシュを頻繁に渡し、b.) これにより大量のメモリを使用する場合にのみ行う必要がある最適化です。
Rafe が既に述べたように、100 個の要素を持つハッシュはそれほど大きくありません。ハッシュ参照を使用しても、通常のハッシュを使用するよりも多くの利点は得られないと主張する人もいるかもしれませんが、特に不利な点もありません (少なくとも私はこれに遭遇したことはありません)。したがって、時期尚早の最適化は、人が考えるほど悪くはありません。
スクリプトの実行が遅すぎる場合は、プロファイラーを使用して時間を無駄にしている場所を見つけることができます。
申し訳ありませんが、その記事がそうであるとすれば、その記事は間違っていました。参照を逆参照してからハッシュ要素にアクセスすると、ハッシュ要素にアクセスするよりも時間がかからない方法はありません。
>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
...
とはいえ、逆参照にかかる余分な時間は問題にならないほどわずかであるべきです。