编译 .NET 1.1 COM 时的性能提升使用.NET 3.5编译器的组件代码
我需要使用 Enterprise Services 以 COM+ 组件的形式构建服务。
该服务现在正在运行。它获取一个字符串，进行一些拼写检查并返回一个字符串。
我的问题是：
该组件是在 .NET 1.1 中编译的，但我的环境很快就会更改为 .NET 3.5。 那么，如果我在 .NET 3.5（实际上是 2.0）中编译代码，我会有什么好处吗？仅在.NET3.5中编译对性能有何影响？
请记住，我没有使用任何 .NET3.5 功能（甚至 WCF）！
感谢您的帮助。
I need to build a service in form of a COM+ component using Enterprise Services.
The service is working right now. It gets a string does some spell-checking and returns a string.
My question is:
This component was compiled in .NET 1.1 but my environment is going to change to .NET 3.5 soon.
So if I compile the code in .NET 3.5 (which is 2.0 actually) will I have any benefit? Any change in performance only by compiling in .NET3.5?
Bear in mind that I'm not using any .NET3.5 functionalities (or even WCF)!
Thanks for the help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
CLR 和库进行了优化（例如启动速度更快），但很难说您是否会看到任何真正的速度差异。
字符串操作意味着内存分配意味着垃圾收集器的压力，所以在 3.5 中应该会好一点。
抱歉，您只能通过测试和测量才能得到真正的答案。
There have been optimizations in the CLR and the libraries (startup is faster for example), but it is difficult to say if you'll see any real speed difference.
String manipulation implies memory allocations implies pressure on the garbage collector, so it should be a bit better in 3.5.
You'll only get a real answer by testing and measuring, sorry.
速度方面 - 也许（但请注意，.Net 3.5 甚至比 1.1 还要大，因为它包含了 LINQ、WCF、CF、WPF 等新技术）。
部署 - .net 3.5 会很好，因为最新的 Windows 操作系统已经有了 .Net 3.5。 Net Framework 3.0+ 可作为其系统上的一项功能。
维护 \ 未来的考虑因素 - .net 3.5。现在迁移到 .Net 3.5 会更好，因此如果您需要对软件进行更改，您已经可以受益于可用的更新技术...
Speed wise - maybe (But take note that .Net 3.5 is even bigger than 1.1 since it includes new technologies such as LINQ, WCF, CF, WPF, etc.)
Deployment - .net 3.5 will be good since latest windows OS already has .Net framework 3.0+ available as a feature on its system.
Maintenance \ Future Considerations - .net 3.5. It will be better for you to migrate now on .Net 3.5 so if you will need to do changes on your software you can already benefit to much newer technologies available...
如果您不更改代码而使用更新的功能（例如通用集合），则不会有太大变化。而且大多数较新的操作系统无论如何都没有安装 .NET 1 或 1.1，而是使用 .NET 2 运行时（3.5 也使用该运行时）运行代码。因此，您仍然应该受益于更好的抖动、互操作等，这些可能在新版本的运行时中得到了增强。
对于普通应用程序，可以在配置文件中指定应使用哪个框架版本，这样即使对于 1/1.1 应用程序，您也可以强制使用 .NET 2 运行时。不过，不确定这是否以及如何适用于 COM 激活的东西。
If you don't change the code the use newer features, such as generic collections, it's not going to change much. And most newer OS don't have .NET 1 or 1.1 installed anyways and run the code using the .NET 2 runtime (which is the runtime also used by 3.5). Therefore, you should still benefit from better jitting, interop etc. which may have been enhanced in the newer versions of the runtime.
For normal applications, one can specify in a config file which framework version shall be used, so that you can enforce the use of the .NET 2 runtime even for a 1/1.1 application. Not sure if and how this works for COM activated things, though.
加载程序集和 JIT 编译其代码已经在 .NET 1.0 中进行了大量优化。非常重要，因为它直接影响任何 .NET 应用程序的启动时间。 2.0 CLR 并没有显着改善这一点。
不过，.NET 3.5 SP1 中对安全策略进行了更新。当程序集位置可信时，不再检查程序集的强名称。确切的规则记录在此处 。这可以使热启动速度加快 40%。这是一个乐观的数字，YMMV。
Loading assemblies and JIT compiling their code was already heavily optimized in .NET 1.0. Very important since it directly affects the startup time for any .NET app. The 2.0 CLR hasn't dramatically improved this.
There was however an update in .NET 3.5 SP1 to the security policy. The strong name of an assembly is no longer checked when the assembly location is trusted. The exact rules are documented here. This can make warm starts faster by as much as 40%. That's an optimistic number, YMMV.