都说Dapper性能好，突然就遇到个坑，还是个性能问题
本来闲来无事，准备看看Dapper扩展的源码学习学习其中的编程思想，同时整理一下自己代码的单元测试，为以后的进一步改进打下基础。
突然就发现问题了，源码也不看了，开始改代码，改了好久。
测试Dapper.LiteSql数据批量插入的时候，耗时20秒，感觉不正常，于是我测试了非Dapper版的LiteSql的批量插入，仅需100毫秒，速度差了200倍。
同样的数据库、同样的Npgsql.dll、同样的测试代码，产生的SQL和参数集合也是一样的，最后不得不怀疑Dapper。
引用Dapper的源码，修改调试之后，我决定提个PR。我之前没想过提PR，我想我也不是为了提PR而提PR，我也不想费时费力。
没想到提PR的过程很不顺利。
先是提交了一行代码，认为没有问题，结果被打了个叉。仔细一看才发现，原来是单元测试不通过。
改了又改，有几个存储过程相关的单元测试总是不通过。
都快要放弃了，后来想到是不是我定义的cleanNames变量随着DynamicParameters类的创建，又清空了，但cleanNames又不能定义成全局的。后来我加了几行代码。
一共提交了12次，单元测试终于全部通过，共增加了11行代码。
PR是提交了，是否被采纳就不知道了。也许代码写的比较挫，也许审核人员不认可我对Dapper的这种用法，是我用错了，没有修改的必要。
修改DynamicParameters.cs文件
变量定义：
private readonly HashSet<string> cleanNames = new HashSet<string>();
单元测试始终无法全部通过，我添加了下面几行代码，终于成功了。原来cleanNames被重新new了之后，command.Parameters里可能是有值的，它的作用域更大一些。
foreach (IDbDataParameter param in command.Parameters)
{
if (!cleanNames.Contains(param.ParameterName))
{
cleanNames.Add(param.ParameterName);
}
}
关键的修改就一行
原代码(参数很多时性能不行，参数什么情况下会很多呢？就是通过一条SQL批量Insert时会有很多参数，我是500条数据插入一批，参数根据表字段多少可能有几千个)：
bool add = !command.Parameters.Contains(name);
当command.Parameters中有几千个参数的时候，性能就惨不忍睹了。
集合查找的时间复杂度是O(N/2)。
修改为(HashSet性能很高)：
bool add = !cleanNames.Contains(name);
通过HashSet查找，时间复杂度是O(1)。
往cleanNames中添加字段名：
if (add)
{
command.Parameters.Add(p);
cleanNames.Add(name);
}
总结
-
关于List集合的Contains方法
当你使用Contains方法的时候，你要考虑这个集合有没有可能突然变的数据量很大？如果是在循环中频繁调用，并且List的数据量比较大，它的性能就比较差，建议使用HashSet或Dictionary来判查找。
但是HashSet、Dictionary和List转来转去也有代价，IDbCommand接口的Parameters属性的类型是IDataParameterCollection，它是一个集合，并没有HashSet或Dictionary类型的属性，又必须要转换才能得到。
LiteSql源码
LiteSql源于DBHelper，里面的接口是做过实际项目的，主要是ERP、CRM系统。
简单支持了Lambda表达式、增加了SqlString之后，使用上似乎变复杂了一点，不过原来的使用方式依然支持。
也许这里面的接口和设计思想，体现的是我上家公司的前辈们的技术水准。比如实体类用partial修饰分成两个文件，可能有利有弊吧。自动生成的Model类是不建议修改的，否则数据库变动的时候你还怎么自动生成？不把你的改动冲掉了？
一个ORM有它的设计思想和理念，比如DapperExtensions就不建议对实体类加特性，而是通过独立的映射类来处理表、字段别名，优缺点我还不清楚。
LiteSql的后续改进，还没有新的指导思想，所以一直都是小改，基本没怎么动。
//gitee.com/s0611163/Dapper.LiteSql
//gitee.com/s0611163/LiteSql
即使是大名鼎鼎的Dapper我依然不放心，所以保留了ADO.NET的版本。
