2012-06-11 14 views
8

プログラムを実行するときにキャッチブロックに入ることに多少のコストがかかることは知っていますが、try {}ブロックを入力しても影響があったのでしょうか? Googleでは多くの意見がありますが、ベンチマークはまったくありません。私が見つけたいくつかの答えは以下の通りであった。JavaのベンチマークTry/Catchブロック

  1. Java try/catch performance, is it recommended to keep what is inside the try clause to a minimum?
  2. Try Catch Performance Java
  3. Java try catch blocks

しかし、彼らは事実を私の質問に答えなかったので、私は自分自身のためにそれをしようとすることを決めました。

ここに私がしたことがあります。私はこのフォーマットでcsvファイルを持っている:

host;ip;number;date;status;email;uid;name;lastname;promo_code;

状態の後、すべてがオプションであり、さらには対応していません。

。ので、値が存在するかどうかを確認するためにバリデーションを解析する必要がある場合は、ここでtry/catchの問題が私の頭に浮かんできました。

StringTokenizer st=new StringTokenizer(line,";"); 
String host = st.nextToken(); 
String ip = st.nextToken(); 
String number = st.nextToken(); 
String date = st.nextToken(); 
String status = st.nextToken();        
String email = ""; 
try{ 
    email = st.nextToken(); 
}catch(NoSuchElementException e){ 
    email = ""; 
} 

、それはそれは、UID、名前、姓とpromo_codeとの電子メールのために行われているものに繰り返す:

私は私の会社に継承された現在のコードは、この行います。

と私はにすべてを変えた:

if(st.hasMoreTokens()){ 
    email = st.nextToken(); 
} 

、実際にそれがより速く実行されます。オプションの列を持たないファイルを解析するとき。ここでは平均的な時間は、次のとおりです。

--- Trying:122 milliseconds 
--- Checking:33 milliseconds 

は、しかし、ここで私と私が求めている理由を混同ものです:CSVのすべての8000行でオプションの列の値で例を実行している場合は、IF()バージョンは、まだtry/catchバージョンよりも優れているので、私の質問は

本当にtryブロックは自分のコードに影響しませんか?この例の

平均時間は以下のとおりです。

--- Trying:105 milliseconds 
--- Checking:43 milliseconds 

誰かがここで何が起こっているか説明できますか?

どうもありがとう

+0

条件を毎回チェックすると、プログラムの実行が遅くなります。複数のIF文を持つことはお勧めできません。あなたの会社のアプローチは理解できるようです。エラーが発生したときはいつでも、ブロックをキャッチしてその内容を確認できます。 –

+0

私はこれを二度としません。彼の場合、電子メールはオプションであるため、トークンを持たない 'st'は例外的なケースではありませんが、非常に頻繁に発生する可能性があります。ここで例外を使うのは良いスタイルではありません。 – gexicide

+0

非常に頻繁に起こるだけでなく、デフォルトの動作です。私たちは多くの小さな機会にのみオプションのフィールドを取得します – hectorg87

答えて

10

はい、(Javaで)任意のパフォーマンスへの影響はありませんしてみてください。コンパイラはtryブロックのVM文を生成しません。これは、tryブロックがアクティブである間のプログラムカウンタを記録し、この情報をクラスファイルのメソッドに付加します。次に、例外がスローされると、VMはスタックを巻き戻し、そのフレーム内のプログラムカウンタが関連するtryブロックにあるかどうかを各フレームでチェックします。これは(スタックトレースを構築することと一緒に)非常にコストがかかるので、キャッチするのは高価です。しかし、試みは無料です:)。

ただし、通常の制御フローでは例外を使用することをお勧めしません。

あなたのコードがより速く実行する理由は、おそらく捕まえることが非常にコストがかかり、単純な試みでチェックを置き換えることによって節約される時間よりも重要です。

try catchは、キャッチが非常に頻繁にトリガーされないコードではより高速にすることができます。たとえば、tryを10000回実行しても1回だけキャッチすると、tryメソッドはif-checkより速くなります。それでも、これは良いスタイルではなく、より多くのトークンを明示的にチェックするあなたのやり方を優先することです。

+0

ありがとう、私は本当にこれを理解しますが、私が試したコードはそうでなければ、それは実行時にいくつかのオーバーヘッドを与えるtry {}を実行し、それは私の質問についてです。私はテストコードをどこかに貼り付けることができますので、試してみてください。 – hectorg87

+0

大丈夫ですまあ、問題は、tryを最適化するのが難しいことかもしれません。ただし、パフォーマンスの影響は無視できます。経験則として、最適化の理由からtry/catchを使ってifを交換することは決して考えないでください。例外的な振る舞いや、通常の制御フローの場合は、try/catchを使用してください。他のすべてはハックです。 – gexicide

+0

私が質問で与えた時間は、1)常にキャッチブロックに入るとき(8000回* 5列)、2)キャッチブロックに入っていないときいつもオプションの列が常に存在するためです – hectorg87