是否存在Rope数据结构比字符串生成器更有效的情况？有些人认为rope数据结构在速度方面几乎从来没有比原生字符串或字符串生成器操作的典型情况好，所以我很想看看这是真的，而且rope确实更好。SGIC++实现的文档详细说明了大O行为和常量因子，它们具有指导意义。他们的文档假定涉及非常长的字符串，引用的示例讨论了10MB的字符串。很少有程序是为处理这些问题而编写的，对于许多类别的问题，将它们重写为基于流，而不是尽可能要求完整的字符串，将导致明显更好的结果。当您可以将绳索正确地视为一部分（绳索本身）而不仅仅是一个字符序列时，这种绳索用于非兆字节序列的非流式操作。重要优点：Rope允许延迟加载子字符串，直到需要为止重要缺点：这导致一些“明显”的使用（SGI明确提到）。对发生主要操作的DNA片段进行操作，但实际上输出很少的多线程算法来更改字符串的局部部分。这些情况理论上可以分成单独的线程和核心，而不必获取子部分的本地副本然后重新组合它们，从而节省大量内存并避免最后进行昂贵的串行组合操作。在某些情况下，字符串中特定于域的行为可以与相对简单的Rope实现扩展相结合，以允许：正如您从列出的示例中看到的那样，所有这些都属于“利基”类别。此外，如果您愿意/能够将算法重写为流处理操作，则有多种选择可能会产生更好的结果。这个问题的简短回答是肯定的，这几乎不需要解释。当然，在某些情况下，Rope数据结构比字符串生成器更有效。它们的工作方式不同，因此它们更适合不同的目的。（从C#的角度来看）在某些情况下，作为二叉树的绳索数据结构更好。当您查看非常大的字符串值时（想想来自SQL的100+MBxml），绳索数据结构可以使整个事物远离大对象堆，其中字符串对象在传递85000字节时命中它。如果您正在查看5-1000个字符串，它可能不会提高性能，值得这样做。这是为5%极端情况设计的数据结构的另一种情况。第十届ICFP编程大赛基本上靠的是使用rope数据结构的人高效求解。这是让VM在合理的时间内运行的重要技巧。如果有很多前缀（显然“prepending”这个词是由IT人员编造的，不是正确的词！）字符串非常好，可能更适合插值；StringBuilders使用连续的内存，所以只能有效地追加。所以StringBuilder非常适合通过附加片段来构建字符串——一个完全正常的用例。由于开发人员需要做很多事情，StringBuilders是一种非常主流的技术。Rope非常适合编辑缓冲区，例如企业级TextArea背后的数据结构。所以（松散的绳索，例如链表而不是二叉树）在UI控件世界中非常普遍，但这并不经常暴露给这些控件的开发人员和用户。你需要非常大量的数据和搅动才能让绳索得到回报——处理器非常擅长流操作，如果你有RAM，那么简单地重新分配前缀对于正常用例来说是可以接受的。顶部提到的那个游戏是我唯一一次看到它需要什么。大多数高级文本编辑器将文本主体表示为“一种绳索”（尽管在实现中叶子通常不是单个字符，而是文本的运行），主要是为了改进对大文本的频繁插入和删除。通常，StringBuilder针对追加进行了优化，并尝试在不过度分配的情况下尽量减少重新分配的总数。典型的保证是（log2N分配，小于2.5倍内存）。通常，字符串构建一次，然后可以长时间不加修改地使用。绳索针对频繁的插入和删除进行了优化，并尽量减少复制的数据量（通过大量分配）。在线性缓冲区实现中，每次插入和删除都变为O(N)，并且通常必须表示单个字符插入。JavascriptVM通常使用字符串来表示字符串。HiggsJavascriptVM的开发者MaximeChevalier-Boisvert说：在JavaScript中，你可以使用字符串数组并最终使用Array.prototype.join来快速连接字符串，O(n)，但JS程序员倾向于“自然”构建字符串的方法是使用+=运算符附加来逐步构建它们。JS字符串是不可变的，因此如果不在内部进行优化，则增量附加是O(n2)。我认为绳索很可能在JS引擎中实现，特别是因为SunSpider基准测试附加了字符串。JS引擎实现者使用rope通过制作以前速度较慢的东西来获得优势。如果不是那些基准测试，我认为社区中关于字符串追加性能不佳的呼声可能已经被“使用Array.prototype.join，dummy！”所满足。除了。以上就是C#学习教程：Rope数据结构有没有比字符串生成器更有效的情况分享的全部内容，如果对你有用还需要详细了解C#学习教程，希望大家多多关注——本文来自网络收藏，不代表立场，如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
