※この書き方は最新のLambdicSqlとは異なります。速度計測の記録なので以前のままにしております。
前回ので、Dapperに完敗を喫したわけですが、ここで勝負を投げるわけにはいかないですね。改善策を考えてみました。
遅いのは、コンパイル
他にも要因はあるかもしれませんが、まずは分かりやすいところからつぶしていきましょう。
パラメータ
※2016/07/12 この仕様やっぱりやめました。
次回へ続く。
今までの仕様だと、どうやってもコンパイルなしには取れないんじゃないかなー。(←いや取れるかも)なので少し面倒になりますが、パラメータを別途渡せるようにしました。pの型を第二引数で決定するというところが微妙。あまり速度が気にならない人は、今まで通り書けます。ミリ秒を争う場合はこれを使うってことでどうでしょう?
α0.0.20で一旦Whereだけに実験的に実装してみました。
[TestMethod] public void CheckLambdicSqlCondition() { var times = new List<double>(); using (var connection = new SqlConnection(TestEnvironment.ConnectionString)) { connection.Open(); for (int i = 0; i < 10; i++) { var watch = new Stopwatch(); watch.Start(); var datas = Sql.Query<DB>().SelectFrom(db => db.TableValues). //★Dapperと同じようにパラメータを渡す Where((db, p) => db.TableValues.IntVal == p.val, new { val = 1 }). ToExecutor(connection).Read().ToList(); watch.Stop(); times.Add(watch.Elapsed.TotalMilliseconds); } } ShowTime(times); }
それで、このDapperのコードと速度を比べてみます。
[TestMethod] public void CheckDapperCondition() { var times = new List<double>(); using (var connection = new SqlConnection(TestEnvironment.ConnectionString)) { connection.Open(); for (int i = 0; i < 10; i++) { var watch = new Stopwatch(); watch.Start(); var datas = connection.Query<TableValues>("select IntVal, FloatVal, DoubleVal, DecimalVal, StringVal from TableValues where IntVal = @Id;", new { Id = 1 }).ToList(); watch.Stop(); times.Add(watch.Elapsed.TotalMilliseconds); } } ShowTime(times); }
結果は・・・
良くなってきたのですが、LambdicSqlの方は、たまに重い時がある。Dapperの方は何回かやってみても、これがないんですよねー。
(msec) | LambdicSql | Dapper | |
---|---|---|---|
1 | 2.4131 | 2.1083 | 初回はいいとして |
2 | 0.8455 | 0.7581 | |
3 | 0.8299 | 0.745 | |
4 | 0.8381 | 0.7671 | |
5 | 0.8254 | 0.7499 | |
6 | 0.8315 | 0.7466 | |
7 | 0.8168 | 0.7483 | |
8 | 3.0112 | 0.7429 | ※なにこれ? |
9 | 0.9152 | 0.7503 | |
平均 | 1.258522222 | 0.901833333 |
そろそろプロファイラ使うか。
もっと真面目な計測は?
とりあえず、ここを超えたら、もう少し真面目にやります。
(まだお手本のDapperのテストプロジェクトのビルド通せてない)