Application.Run 是我的应用程序中最消耗 CPU 的函数；我可以优化什么？
我的 WPF 应用程序有一个功能，可以在后台渲染大量图像，同时在新图像准备就绪时更新 UI。
分析此过程表明，Application.Run 是完成最多工作的函数，占 43%，“第二昂贵”位置由三个图形 API 共享，每个占 6%。
我可能在做什么，会导致在 Application.Run 上花费如此多的时间？看来这个方法的核心是运行我的应用程序的主调度程序，但这并不能帮助我弄清楚调度程序正在做什么。我可以获得更细粒度的个人资料吗？
注意：我的意思是System.Windows.Application.Run。
My WPF application has a feature whereby it renders a large number of images in the background while updating the UI whenever a new image is ready.
Profiling this process has shown that Application.Run is the function doing the most work, at 43%, with the "second most expensive" spot shared by three graphics APIs, each at 6%.
What might I be doing that would cause so much time to be spent in Application.Run? It seems that the core of this method is running the main dispatcher for my app, but that doesn't help me figure out what it is that the dispatcher is doing so much. Can I get a more fine-grained profile?
Note: I mean System.Windows.Application.Run.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
事实证明，Visual Profiler（WPF Performance Suite 的一部分）可以提供更详细的 CPU 使用情况细分：
这显示了一半无法解释的 CPU 使用率取决于渲染线程（因此也许我应该减少更新 UI 的频率），其余大部分都花费在我的 Invoke 回调中（这在我的情况下是不可避免的）。
Turns out that the Visual Profiler (part of the WPF Performance Suite) can provide a more detailed break-down of the CPU usage:
This shows that half of that unexplained CPU usage is down to the rendering thread (so perhaps I should update the UI less frequently), and much of the rest is spent in my Invoke callback (which is unavoidable in my case).