“dll”我假设您的意思是从托管的 .net 代码转换为非托管的“本机”编译代码。是的,这种方法会有所帮助。
这在很大程度上取决于。请记住,循环代码的速度在典型的 i3 上可能只有 25 秒(这是循环到 100 亿次但没有做任何其他事情的成本和开销)。
我假设你去了项目,然后编译。在该屏幕上选择高级编译。在那里您要检查删除整数溢出检查。确保循环变量是整数以提高速度。
此时,什么都不做的“基本”循环将从大约 20 秒下降到大约 6 秒。
这就是基本循环速度 - 现在归结为我们在该循环内所做的事情。
此时,.net 确实有一个 JIT(一个即时本地编译器)。这意味着您的源代码会转到“CLR”代码,然后该代码确实会被编译为本机 x86 汇编代码。所以这“确实”将源代码降到了真正的机器代码级别。然而,JIT 肯定没有那么高效,也不能花“时间”优化代码,因为 JIT 必须在你不注意的情况下“飞速”工作。所以一个 c++(或原生编译时运行速度与 c++ 一样快的 VB6)当然可以运行得更快,但问题是提高多少?
优化后的编译器可能会在实际 LOOPING 代码等方面获得另一倍的速度。
但是,在这两种情况下(使用 .net 托管代码,或编译为本机英特尔代码的代码),它们都可能调用相同的例程来计算!
换句话说,如果 80% 的代码花在执行数学运算等的“库”代码中,那么从 c++ 调用此类代码或从 .net 调用此类代码将产生非常小的差异,因为 BULK工作花费在相同的系统代码中!
上述概念实际上是“主管”模式与您的应用程序模式。
换句话说,您的代码所花费的时间与使用系统“库”代码所花费的时间相比,意味着大部分的提升都发生在主管代码中。这意味着从 .net 跳转到原生 c++/vb6 dll 不会对性能产生太大影响。
所以我首先要确保代码中的循环和数组索引引用是整数类型。上面关于取消边界检查的提示可能会让您“接近”使用 .dll 的提示。更糟糕的通常是“洗牌”两个数据的时间,并且从那个 external.dll 子中花费的时间比在处理方面节省的时间要多。
如果您的例程正在执行数据库或文件 i/o,那么所有的赌注都没有了,因为这是非常不同的问题。
所以我会首先在 [x] 删除整数溢出检查关闭的情况下测试/尝试您的应用程序。并确保在测试期间使用 ctrl-F5 代替 F5 来运行代码而无需调试。上述溢出检查和选项在调试模式下不会显示速度提高。
所以很难说 - 这实际上取决于您正在执行多少数学运算(尤其是浮动调用)(主管代码)与仅在数组中移动值的数学运算。如果更多的代码在移动,那么我建议上面的整数优化,去一个 .dll 可能不会有太大帮助。