在64位JIT和32位JIT下运行.NET应用程序时,在性能,内存等方面出现了不寻常的意外后果？我对好事感兴趣,但对人们遇到的令人惊讶的糟糕问题更感兴趣.
我正在编写一个新的.NET应用程序,它将部署在32位和64位.关于移植应用程序的问题有很多问题 - 从编程/移植的角度来看,我并不关心"陷阱".(即:正确处理本机/ COM互操作,嵌入在结构中的引用类型,更改结构的大小等)
然而,这个问题和它的答案让我思考 - 我还有什么其他问题可以忽略？
有很多问题和博客文章绕过这个问题,或者涉及到它的一个方面,但我还没有看到任何编制了一个很好的问题清单.
特别是 - 我的应用程序非常受CPU限制并且具有巨大的内存使用模式(因此首先需要64位),以及本质上是图形化的.我关心在64位Windows上运行的CLR或JIT中可能存在的其他隐藏问题(使用.NET 3.5sp1).
以下是我目前了解的一些问题:
(现在我知道了)属性,甚至是自动属性,都没有在x64中内联.
由于引用的大小,应用程序的内存配置文件也会更改,但也因为内存分配器具有不同的性能特征
启动时间可能会受到x64的影响
我想知道人们在64位Windows上的JIT中发现了哪些其他具体的问题,以及是否有任何性能方面的解决方法.
谢谢你们!
- - 编辑 - - -
只是为了澄清 -
我知道尝试早期优化通常很糟糕.我知道第二次猜测系统通常很糟糕.我也知道64bit的可移植性有其自身的问题 - 我们每天在64位系统上运行和测试以帮助解决这个问题.等等
但是,我的应用程序不是典型的业务应用程序.这是一个科学的软件应用程序.我们有许多流程可以在所有核心(高度线程化)上使用100%CPU,每次数小时.
我花了很多时间来分析应用程序,这会产生巨大的差异.但是,大多数分析器都会禁用JIT的许多功能,因此当您在分析器下运行时,内存分配,JIT中的内联等小细节可能很难确定.因此我需要这个问题.
京公网安备 11010802040832号 | 京ICP备19059560号-6 