以前, 見えない箇所での無作法は許されるのか? http://blogs.wankuma.com/ognac/archive/2006/07/17/32819.aspx
で IsDateは変だと書いたのですが,ジャンヌさんから, TryParseの件で゜アドバイスを頂き,
気になったので,framework2.0の環境を構築し,速度測定してみた。
実施してみて,改めて,関心することになった。
環境:プロセッサ x86 Family 15 Model 2 Stepping 7 GenuineIntel ~2394 Mhz
BIOS バージョン/日付 Phoenix/Award Technologies, LTD 6.00 PG, 2003/04/03
合計物理メモリ 1,024.00 MB
バージョン = "5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)"
VS2005(Professional) で実行。
単位は 1.命令あたりの μ秒を算出してある。 小数点以下3桁で表示
(OKのみ) は対象データがすべて正しい場合:
Dim OKのみ() As String = New String() {"2006/12/12", "2007/12/12", "2006/10/10", "2006/02/30"}
(NGあり) は対象データのなかにNGデータを含めた場合:
Dim NGあり() As String = New String() {"2006/02/31", "", Nothing, "2006/02/30"}
これを DateTime.tryparse(str) ,IsDate(str),Convert.ToDateTime(str) で10回実施し,平均をとってみた。
基準として 10 + 20 の加算式での結果をとり結果は0.004μ秒 となりました.これを基準にした。
●DateTime.tryparse(OKのみ) 8.385μ秒
VB.DateTime.tryparse(NGあり) 4.123μ秒
●Isdate(OKのみ) 131.333μ秒
Isdate(NGのみ) 65.087μ秒
●Convert.ToDateTime_OK(OKのみ)10251.863μ秒 : try Catchで処理
Convert.ToDateTime_OK(NGあり)10417.849μ秒 : try Catchで処理
となった。 興味深い結果である。isDate/TryParseでは, NGがあったほうが,早いのである。
事前に NGのDataは除外し,OKデータのみで判定している模様。
ということは,有効なデータの型変換が遅い.(かな?)
Convert.ToDateTime は 非日付の時,例外が発生するので,自前でCatchしたので,異なる結果になった模様。
これにより、
Isdateは tryParseより 15倍遅い.ので原則禁止.
tryparse()の事前に, 明らかに日付を構成しない文字列は弾く.
例外のTry/Catch処理は,とてつもなくコストが高いことがわかる。
今以上に,例外を期待するコーディングはダメと叫ぼう。