C#中的字符串串联与内部字符串

如果我实现这样的东西,我永远不会构建StringBuilder(或脚本的任何其他内存缓冲区)。

FileStream f = new FileStream("yourscript.sql");
foreach (Table t in myTables)
{
    f.write("CREATE TABLE [");
    f.write(t.ToString());
    f.write("]");
    ....
}

然后,您就不再需要脚本的内存中表示,以及所有字符串的复制。

意见?

为了你的 ,Win32具有 WriteFileGather 函数,它可以有效地将一组(插入的)字符串写入磁盘,但只有在异步调用时,它才会产生显著的差异,因为磁盘写入将掩盖除超大连接以外的所有连接。

为了你的 主要问题

纯粹作为练习,一些人估计:构建1MB的缓冲区将扫描大约3MB的内存(1MB源、1MB目标、1MB源) 在重新分配期间进行复制)。

是的,列表实现可能更快,如果您的缓冲区大一个数量级,那么差异就很重要了。

对于更常见的小字符串情况,算法增益可以忽略不计,并且很容易被其他因素抵消:StringBuilder代码可能已经在代码缓存中,并且是微优化的可行目标。此外,如果最终字符串适合初始缓冲区,则在内部使用字符串意味着根本没有副本。

使用链表还可以将重新分配问题从O(字符数)减少到O(段数)-字符串引用列表面临与字符串相同的问题!

不过,如果能比较一下这两种想法,以及当列表开始变快时,那将是一件有趣的事情。

根据我的经验,对于大量的字符串数据,我正确分配的StringBuilder比其他任何东西都好。浪费一些内存是值得的,甚至,为了防止重新分配,将您的估计超出20%或30%。我目前没有用我自己的数据来备份它的硬数据,但是看看 this page for more .

However, as Jeff is fond of pointing out, don't prematurely optimize!

编辑:正如@Colin Burnett所指出的,Jeff进行的测试与Brian的测试不一致,但是链接Jeff的帖子的重点是一般的过早优化。杰夫页面上的几位评论员指出了他的测试存在的问题。

StringBuilder 使用 String 内部。 一串 实际上,在 System 组装,这就是为什么 可以建立在它之上。你可以

字符串内部处理适用于可在编译时识别的字符串。因此,如果您在执行过程中生成了大量字符串,它们将不会被插入,除非您自己通过对字符串调用interning方法来执行。

"SOMESTRINGA" 和 "SOMESTRINGB" 将是两个不同的字符串,即使他们被拘留。

如果所有(或大部分)被连接的字符串都是内部的,那么您的方案可能会给您带来性能提升,因为它可能会占用更少的内存,并且可以节省一些大型字符串副本。

唯一的方法是使用这两种方法运行应用程序并测量结果。然而,除非您面临巨大的内存压力,并且需要一种节省字节的方法,否则我不会费心,只会使用字符串生成器。

A. StringBuilder char[] 字符串拼接 仅将内部字符串缓冲区作为常规字符串返回。

字符串拼接 字符串拼接

然而,为了获得一点透视图,你应该看看你试图优化的是什么。在您的程序中,需要花费的大部分时间是将数据实际写入磁盘,因此,即使您可以优化字符串处理,使其速度比使用 字符串拼接

关于字符串最慢的是malloc。在32位平台上,每个字符串需要4KB。考虑优化创建的字符串对象数。

string varString1 = tableName;
string varString2 = tableName;

StringBuilder sb1 = new StringBuilder("const expression");
sb1.Append(varString1);

StringBuilder sb2 = new StringBuilder("const expression");
sb2.Append(varString2);

string resultingString = sb1.ToString() + sb2.ToString();

如果perf如此重要的话,我甚至会让计算机通过依赖注入框架来评估对象实例化的最佳路径。