解决从 .net 2.0 转换到 4.0 后的性能问题
我有一个已有 5 年历史的 winforms .net MDI 应用程序，我刚刚使用 vs 2010 将其从 .net 2.0 转换为 4.0...该应用程序现在需要大约 1.5 分钟才能启动，并在 vs 之外启动时打开一个空白表单，大约需要 15 分钟在 vs. 内启动时的秒数（在升级到 .net4.0 和 devexpress 11.2 之前，在任何一种情况下启动应用程序都没有明显的延迟）
不幸的是，也有一些延迟这里有很多变量...就像我们还必须使用新版本的 devexpress 控制库和 xpo 持久层 (orm)。
主窗体有大约 1500 个左右的控件，分布在 devexpress 选项卡控件的 12 个选项卡中。对应用程序进行分析表明，在表单构造函数中，几乎 63% 的时间花费在“clr.dll”中......我现在知道如何解释它。
作为测试，我使用相同的工具构建了另一个应用程序，并在空白表单上放置了 1500 个控件，结果显示该应用程序中不到 1% 的时间花费在该表单构造函数的 clr.dll 上。
这对我来说感觉不对……任何人都可以理解这一点，或者为我指明正确的方向，以继续了解所有时间都在哪里……
我准备好接受结果并说好……我们不能这样做，但事实上我可以创建另一个 devexpress 表单并在其上放置 1500 个控件，当我分析它时，结果更有意义，表单构造函数中的大部分时间都花在了 . ControlsCollection.Add 函数或控件构造函数本身...
任何想法？
谢谢乔纳森
好的...我打开了加载符号，这就是我现在得到的...我必须说这让我担心，因为我在英特尔机器上运行...我也找不到关于 PreStubAmd64 的任何文档称呼。 
I have a 5 year old winforms .net MDI app that i just converted from .net 2.0 to 4.0 using vs 2010... the application now takes about 1.5 minutes to start and open a blank form when starting outside of vs, and about 15 seconds when starting within vs. (there was no noticeable delay in starting app in either scenario prior to uprading to .net4.0 and devexpress 11.2)
Unfortunately, there are a few too many variables here... like we also had to use a new version of the devexpress control library, and xpo persistance layer (orm).
The main form has about 1500 or so controls spreed across 12 tabs of a devexpress tabcontrol. Profiling the application shows that in the form constructor almost 63% of the time is spent in "clr.dll"... and i have now idea how to interpret that.
as a test i built another application with the same tools and dropped 1500 controls on a blank form, and it shows that less than 1 percent of the time in that app is spent in the clr.dll for that form constructor.
This doesn't feel right to me... can anyone make any sense of this or point me in the right direction to continue understanding where all the time is going...
I was ready to just accept the results and say well... we can't do this, but the fact that i can create another devexpress form and drop 1500 controls on it and when i profile it, the results make a lot more sense, the majority of the time in the form constructor is spent in the ControlsCollection.Add function or the control constructors themselves...
any ideas ?
thanks jonathan
OK... i turned on Load symbos, and this is what i get now... and i must say it worries me, as i'm running on an intel machine... I also can't find any documentation on thePreStubAmd64 call.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
嗯...我似乎已经解决了我自己的问题，但我不明白这一切。
因为我已经转换了 2008 年的原始项目，所以 VS 2010 中的目标平台是“任何 Cpu”...（这对我来说很有意义...）。我试图构建一个表现出同样糟糕性能的新应用程序，我注意到我所有的新项目都默认为 x86 并且运行得很好......所以......
在使用配置管理器并为我的问题解决方案创建一个新配置之后以 x86 为目标，我的启动时间从 90 秒缩短到 9 秒...并且我没有看到“theStubAMD64”函数的迹象，该函数占用了我实例化表单的 80% 的时间...哇...
所以对于任何人来说else 转换形式2008 到 2010 并且需要在 x64 下运行，您可能想将目标更改为 x86。 （我确信我错过了各种各样的东西......但我很高兴！）
乔纳森
我不认为有人愿意解释为什么应用程序在 wow64 下比本机 64 位运行得更快......
Well... i appear to have solved my own problem, but i don't understand it all.
Because i had converted the original project from 2008, the target platform in VS 2010 was "Any Cpu" ... (which makes sense to me...). I trying to build a new app that exhibited the same bad performance, i noticed that all my new projects defaulted to x86 and ran great... so...
after playing with the configuration manager and creating a new config for my problem solution that targets x86, my startup time went from like 90 seconds to 9 seconds... and i see no sign of "theStubAMD64" function that was taking up like 80% of my time instantiating the form... wohooo...
so for anyone else converting form 2008 to 2010 and need to run under x64, ya might wanna change the target to x86. (i'm sure i'm missing all sorts of stuff... but i'm happy!)
jonathan
i don't suppose anyone cares to explain why an app would run faster under wow64 than native 64bit...