Mig*_*uel 17 c c# c++ performance multithreading
我写了一个程序,它在C#中的字符串一些繁重的工作的一部分.我最初选择C#,不仅因为它更容易使用.NET的数据结构,还因为我需要使用这个程序来分析数据库中的一些2-3万的文字记录,它是非常容易使用C#连接到数据库.
人们普遍认为是拖慢整个代码程序的一部分,我决定使用指针在字符串中使用每一个字符重写它的C,并且采取了一些119秒来分析10,000,000字符串代码现在的一部分C#只需5秒即可获得C代码!性能是当务之急,所以我正在考虑用C重写整个程序,它编译成DLL(一些东西,我不知道该怎么办时,我开始写程序),使用的DllImport从C#中使用它的方法工作用数据库字符串.
考虑到重写整个程序需要一些时间,而且因为使用DllImport来处理C#的字符串需要编组等等,我的问题是C dll更快的字符串处理带来的性能提升是否会超过必须重复编组字符串的性能损失从C#访问C dll？
Mar*_*tos 10
一种选择是将C代码重写为不安全的C#,它应该具有大致相同的性能并且不会产生任何互操作性惩罚.
Ste*_*end 10
首先,分析您的代码.您可能会发现一些真正的headmacker可以大大加快C#代码的速度.
其次,使用指针在C中编写代码并不是一个公平的比较.如果您打算使用指针,为什么不用汇编语言编写它并获得真正的性能呢？(不是真的,只是减少荒谬.)对本机代码的更好比较就是使用std::string.这样你仍然可以从string类和C++异常安全中获得很多帮助.
鉴于您必须从数据库中读取2-3百万条记录来完成这项工作,我非常怀疑破解字符串所花费的时间将超过从数据库加载数据所花费的时间.因此,请考虑如何构建代码,以便在数据库负载正在进行时开始字符串处理.
如果你使用SqlDataReader(比如说)顺序加载行,应该可以尽可能快地批量处理N行,然后交给一个单独的线程进行后处理,这是你当前头痛和这个问题的原因.如果你在.Net 4.0上这是最简单的使用任务并行库,System.Collections.Concurrent也可用于线程之间的结果整理.
这种方法应该意味着DB延迟和字符串处理都不是一个显示停止的瓶颈,因为它们并行发生.即使您使用的是单处理器计算机,这也适用,因为您的应用程序可以在等待下一批数据通过网络从数据库返回时处理字符串.如果您发现字符串处理最慢,请使用更多线程(即Task.s).如果数据库是瓶颈,那么您必须查看外部方法以提高其性能 - 数据库硬件或架构,网络基础架构.如果在处理更多数据之前需要掌握一些结果,TPL允许在Tasks和协调线程之间创建依赖关系.
我的观点是,我怀疑在本地C或其他任何地方重新设计整个应用程序的痛苦是值得的.有很多方法可以给这只猫上皮.