lambdicSql - パフォーマンス改善せねば -

マッピングする型の生成

これは素直にキャッシュすることにしました。一回はコンパイルしますけどね。

パラメータ

※2016/07/12 この仕様やっぱりやめました。
次回へ続く。

今までの仕様だと、どうやってもコンパイルなしには取れないんじゃないかなー。(←いや取れるかも)なので少し面倒になりますが、パラメータを別途渡せるようにしました。pの型を第二引数で決定するというところが微妙。あまり速度が気にならない人は、今まで通り書けます。ミリ秒を争う場合はこれを使うってことでどうでしょう？
α0.0.20で一旦Whereだけに実験的に実装してみました。

[TestMethod]
publicvoid 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]
publicvoid 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の方は何回かやってみても、これがないんですよねー。

そろそろプロファイラ使うか。