为什么activex控件在vb5中运行速度比.net快3倍？

本文介绍了为什么activex控件在vb5中运行速度比快3倍？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我对National Instruments Active-xStrip Chart做了基准比较。控制在Vb5和vb（2005）。代码相同： I = 1到10000 ARR（1,0）= J AxCWGraph1.ChartY （arr） j = J + 1 如果是j 10则j = 0 下一页 运行VB5 exe需要0.8秒，运行一台 exe需要3秒钟（同一台机器）。 我意识到一个组件将是更好的方式来代替 在中使用active-x，但为什么巨大的速度差异？ 谢谢， 巴特

Hi, I did a benchmark comparison of a National Instruments Active-x "Strip Chart" control in both Vb5 and vb(2005). The code is identical: For I = 1 to 10000 ARR(1,0) = J AxCWGraph1.ChartY(arr) j = J + 1 If j 10 then j = 0 Next It takes .8 seconds for a VB5 exe to run and 3 seconds for a exe to run(same machine). I realize that a component would be the better way to go instead of using active-x in , but why the HUGE speed diff? Thanks, Bart

推荐答案

ba **** @ gmail 在新闻中写道：1162249254.740872.138680 @ e64g2000cwd.googlegroups： ba****@gmail wrote in news:1162249254.740872.138680 @e64g2000cwd.googlegroups: 运行VB5 exe需要0.8秒，运行一台 exe需要3秒钟（同一台机器）。 我意识到一个组件将是更好的方式来代替 在中使用active-x，但为什么是巨大的spe ed diff？ It takes .8 seconds for a VB5 exe to run and 3 seconds for a exe to run(same machine). I realize that a component would be the better way to go instead of using active-x in , but why the HUGE speed diff?

可能是由于几个因素... ActiveX不是mananged代码，所以 ..NET运行时必须编组所有电话。 Marshaling调用消耗额外的 CPU周期。 VB编译本机代码而.NET则不编译。本机代码往往比非本机代码更快地运行。如果速度是最重要的，那么在MSDN上将.NET代码编译成本机代码的工具是 。

Could be due to a couple factors... ActiveX is not mananged code, so the ..NET runtime has to marshal all the calls. Marshaling calls use up extra CPU cycles. VB compiles native code while .NET does not. Native code tends to run faster than non-native code. If speed is of the utmost importance, there are tools on MSDN to compile .NET code into native code.

我有兴趣获得本机编译器。你知道我在哪里 从中完全下载吗？ URL？ （我尝试搜索MSDN但很少见。） Spam Catcher写道： I am interested in getting the native compiler. DO you know where I can download it from exactly? URL? (I tried searching MSDN but turned up little.) Spam Catcher wrote: bartj1_gmail 在新闻中写道：1162249254.740872.138680 _e64g2000cwd.googlegroups: bartj1_gmail wrote in news:1162249254.740872.138680 _e64g2000cwd.googlegroups: 运行VB5 exe需要0.8秒运行（同一台机器）需要3秒的 exe 。 我意识到组件是更好的方法 在中使用active-x，但为什么巨大的速度差异？ It takes .8 seconds for a VB5 exe to run and 3 seconds for a exe to run(same machine). I realize that a component would be the better way to go instead of using active-x in , but why the HUGE speed diff?

可能是由于几个因素... ActiveX不是mananged代码，所以 .NET运行时必须编组所有的调用。 Marshaling调用消耗额外的 CPU周期。 VB编译本机代码而.NET则不编译。本机代码往往比非本机代码更快地运行。如果速度至关重要，那么MSDN上的工具就是将.NET代码编译成本机代码。

Could be due to a couple factors... ActiveX is not mananged code, so the .NET runtime has to marshal all the calls. Marshaling calls use up extra CPU cycles. VB compiles native code while .NET does not. Native code tends to run faster than non-native code. If speed is of the utmost importance, there are tools on MSDN to compile .NET code into native code.

> VB5 exe需要0.8秒运行和 exe运行3秒钟（同一台机器）。 我意识到组件将是更好的方式去使用 active-x in ，但为什么巨大的速度差异？ >It takes .8 seconds for a VB5 exe to run and 3 seconds for a exeto run(same machine).I realize that a component would be the better way to go insteadof using active-x in , but why the HUGE speed diff?

可能是由于几个因素... ActiveX不是mananged代码，所以 .NET运行时必须编组所有的调用。 Marshaling调用消耗额外的 CPU周期。 VB编译本机代码而.NET则不编译。本机代码往往比非本机代码更快地运行。如果速度至关重要，那么MSDN上的工具就是将.NET代码编译成本机代码。

Could be due to a couple factors... ActiveX is not mananged code, so the .NET runtime has to marshal all the calls. Marshaling calls use up extra CPU cycles. VB compiles native code while .NET does not. Native code tends to run faster than non-native code. If speed is of the utmost importance, there are tools on MSDN to compile .NET code into native code.

这是错误的。所有.Net代码都是本机代码。没有解释器。 从来没有。我怀疑有没有。 有一个JIT编译器。 Just In Time * COMPILER"。这将MSIL 编译成本机代码。 请停止传播错误的事实。 至于原始问题，部分速度问题可能来自Visual Studio。首先在发布版本后尝试应用程序。直接运行可执行文件 。 它可能要快得多。 如果它确实更快，你想要更快开发环境，尝试转换一些托管调试助手的b $ b。我做了一些图片 不时处理代码，用MDA调用DLL' 在每次调用之前和之后检查堆栈大小可能很昂贵。

This is WRONG. All .Net code is native code. There is NO INTERPRETER. There never has been. I doubt there ever will be. There is a JIT compiler. Just In Time *COMPILER". This compiles MSIL into native code. Please stop spreading erroneous "facts". As to the original question, part of the speed problem may come from Visual Studio. First try the app after doing a release build. Run the executable directly. It may be much faster. If it is indeed faster, and you want a faster development environment, try turning of some of the managed debugging assistant. I do some image processing code from time to time, and calling into DLL''s with MDA checking the stack size before and after every call can be expensive.