当我分析我的应用程序时,我注意到了这行特殊的代码(它通过处理一些原始数据创建了大量的数据库插入):
myStringBuilder.AppendLine(
string.Join(
BULK_SEPARATOR, new string[]{myGuid.ToString() ...
请记住,生成的字符串最终会出现在通过 TSQL 命令调用的文件中BULK INSERT
,有没有办法可以更快地完成这一步?我知道获取字节数组更快,但我不能将其插入文件中。
当我分析我的应用程序时,我注意到了这行特殊的代码(它通过处理一些原始数据创建了大量的数据库插入):
myStringBuilder.AppendLine(
string.Join(
BULK_SEPARATOR, new string[]{myGuid.ToString() ...
请记住,生成的字符串最终会出现在通过 TSQL 命令调用的文件中BULK INSERT
,有没有办法可以更快地完成这一步?我知道获取字节数组更快,但我不能将其插入文件中。
最快和最简单的方法是根本不使用BULK INSERT
原始文件。而是使用SqlBulkCopy类。这应该通过直接通过管道发送数据而不是使用中间文件来显着加快这一速度。
(您也可以Guid
直接使用,而无需进行任何字符串转换,尽管我不能 100% 确定SqlBulkCopy
它内部的作用。)
您没有指出您从哪里获得指南。另外,我不相信获取字节会更快,因为您将执行 Guid 类上的 ToString 方法已经执行的操作,遍历字节并转换为字符串值。
相反,我认为在性能方面可以改进此代码的一些一般领域是(并假设您在循环中执行此操作):
您是否在循环的新迭代中重用 myStringBuilder 实例?您应该将长度(而不是容量)属性设置为 0,然后使用它重建您的字符串。这将避免必须预热一个新的 StringBuilder 实例,并且已经为更大的字符串分配了内存。
在 myStringBuilder 上使用 Append 调用,而不是调用 String.Join。String.Join 将预先分配一堆内存,然后返回一个字符串实例,您将再次分配该实例(如果在第一次迭代中)或复制到已分配的空间中。没有理由这样做两次。相反,遍历您正在创建的数组(或展开循环,似乎您有一个固定大小的数组)并调用 Append,传入 guid,然后传入 BULK_SEPARATOR。顺便说一句,从末尾删除单个字符更容易,如果您实际附加了 Guid,只需将 StringBuilder 的 Length 属性减一。
如果时间很关键 - 您是否可以提前创建足够长的 GUID 转换为字符串的列表,然后在您的代码中使用它?是在 C# 中,还是在 SQL Server 中,取决于您的要求?