Tag: 性能

替换许多字符串的更好方法 – 在C＃中进行模糊处理

我正在尝试模糊大量数据。 我已经创建了一个我要替换的单词（标记）列表，我正在使用StringBuilder类逐个替换单词，如下所示： var sb = new StringBuilder(one_MB_string); foreach(var token in tokens) { sb.Replace(token, “new string”); } 这很慢！ 我能做些什么简单的事情来加速它吗？ 标记是大约一千个字符串的列表，每个字符串长度为5到15个字符。

为什么Parallel.ForEach比AsParallel（）快得多.ForAll（）尽管MSDN建议不然？

我一直在做一些调查，看看我们如何创建一个贯穿树的multithreading应用程序。 为了找到如何以最佳方式实现这一点，我创建了一个运行在我的C：\ disk中的测试应用程序并打开所有目录。 class Program { static void Main(string[] args) { //var startDirectory = @”C:\The folder\RecursiveFolder”; var startDirectory = @”C:\”; var w = Stopwatch.StartNew(); ThisIsARecursiveFunction(startDirectory); Console.WriteLine(“Elapsed seconds: ” + w.Elapsed.TotalSeconds); Console.ReadKey(); } public static void ThisIsARecursiveFunction(String currentDirectory) { var lastBit = Path.GetFileName(currentDirectory); var depth = currentDirectory.Count(t => t == ‘\\’); //Console.WriteLine(depth + “: ” + […]

在C＃中调用方法时的预热

我刚看到这篇关于时间测量的post 。 我记得（我希望我没有记错）这是一场不公平的比赛，如果以前从未打过这种方法的话。 那是： // At the beginning of the application MyClass instance = new MyClass(); instance.MyMethod(); instance.MyMethod(); // Faster than the first call, because now it’s warmed up. 我们真的在C＃中有这样的热身理论吗？ 如果是，为什么（热身时CLR会做什么）？ 如果这个方法是扩展方法（静态方法），那么一切都是一样的吗？

高效的笛卡尔积算法

有人可以为我演示一个比我目前使用的更有效的笛卡尔积算法（假设有一个）。 我环顾四周，谷歌搜索了一下，但看不到任何明显的东西，所以我可能会遗漏一些东西。 foreach (int i in is) { foreach (int j in js) { //Pair i and j } } 这是我在代码中所做的高度简化的版本。 两个整数是查找键，用于检索一个/多个对象，两个查找中的所有对象一起配对到新对象中。 在一个更大更复杂的系统中，这个小块代码成为一个主要的性能瓶颈，因为它在规模上运行的数据集。 其中一些可能通过改进用于存储对象和所涉及的查找的数据结构来减轻，但我认为主要问题仍然是笛卡尔积本身的计算。 编辑 关于我对算法的具体用法的更多背景，看看是否有任何技巧可以用来回应Marc的评论。 整个系统是一个SPARQL查询引擎，它处理一组Graph数据的SPARQL查询，SPARQL是一种基于模式的语言，因此每个查询都包含一系列与Graph匹配的模式。 在两个后续模式没有公共变量（它们是不相交的）的情况下，有必要计算由两个模式产生的解的笛卡尔积，以获得整个查询的可能解的集合。 可能存在任何数量的模式，我可能需要多次计算笛卡尔积，如果查询由一系列不相交的模式组成，则可能导致可能的解决方案中相当指数级的扩展。 不知何故从现有的答案我怀疑是否有任何技巧可以应用 更新 所以我想我会发布我实施的内容的更新，以便最大限度地减少对笛卡尔积的需求，从而优化查询引擎。 请注意，并不总是可以完全消除对产品的需求，但几乎总是可以优化，因此连接的两组的尺寸要小得多。 由于作为一组三元模式的每个BGP（基本图形模式）作为一个块执行（实质上），引擎可以自由地重新排序BGP中的模式以获得最佳性能。 例如，考虑以下BGP： ?a :someProperty ?b . ?c :anotherProperty ?d . ?ba :Class . 按原样执行查询需要笛卡尔积，因为第一个模式的结果与第二个模式不相交，因此前两个模式的结果是其各自结果的笛卡尔积。 这个结果将包含比我们实际需要的结果更多的结果，因为第三个模式限制了第一个模式的可能结果，但我们直到之后才应用此限制。 但如果我们这样重新排序： ?ba :Class . ?a :someProperty ?b […]