如何在Vb.net winforms中调试慢速屏幕重绘 [英] How to debug slow screen repaint in Vb.net winforms

问题描述

我需要一些帮助来尝试使用我的一个Vb来调试缓慢的重绘问题。 Net WinForms程序。当程序第一次启动时，屏幕重绘得很好。程序运行几个小时后，您可以开始注意屏幕需要更长时间才能重新绘制。程序运行超过24小时后，屏幕重绘大约需要10秒钟。它最终会变得非常慢，你必须关闭程序并重新启动它。重新启动程序后，程序屏幕再次快速重新绘制，但随后程序运行的时间开始减慢。我已经读过可以在具有许多控件的表单上进行缓慢重绘。我最复杂的形式有大约100个控件，不包括很多控件嵌套。



我在多台计算机上运行同样的程序，使用2种不同的操作系统。大多数计算机都运行Windows 2000 SP4，但我们也有一些运行Windows XP。慢重绘问题只发生在运行Windows 2000的计算机上。



我首先想到我的一些GDI对象有内存泄漏所以我运行了GDI视图并找到了我纠正过的一些小问题。现在，当程序运行时，很少有超过100个GDI对象随时打开，而且它似乎不再向上爬。



当我做某些事情时我的测试，我注意到我最初认为是手柄泄漏。我让任务管理器打开了，我注意到句柄上升到大约1500但是然后重置为500.我做了一些调查，发现在后台线程触发通过调用更新GUI线程的事件时，句柄增加了。我的程序中的后台线程每隔几秒就会持续从外部进程捕获相同的数据。我有一个后台线程在Do while循环中运行。手柄增加是否正常？这是我的第一个使用连续操作后台线程的项目，所以我在这方面有点绿色。这是我更新GUI线程的代码：

I need some help trying to debug a slow repaint issue with one of my Vb. Net WinForms programs. When the program is first started the screens repaint just fine. After the program has ran for a few hours, you can start to notice the screens taking longer to repaint. After the program has run for over 24 hours, the screen repaint takes about 10 seconds. It eventually gets to a point where it gets so slow that you have to shut the program down and restart it. After restarting the program, the program screens repaint fast again but then start to slow down the longer the program runs. I’ve read that slow repaint can occur on Forms that have many controls. The most complex form I have has about 100 controls and does not include a lot of control nesting.

I have this same program running on multiple computers which use 2 different operating systems. Most of the computers are running Windows 2000 SP4 but we also have a couple running Windows XP. The slow repaint issue only happens on the computers running Windows 2000.

I first thought I had a memory leak with some of my GDI objects so I ran GDI view and found a few small issues that I have since corrected. Now when the program runs, there is rarely over 100 GDI objects open at any time and it doesn’t seem like its creeping up anymore.

When I was doing some my testing, I noticed what I first thought was a handle leak. I left the task manager open and I noticed that the handles went up to about 1500 but then reset back down to 500. I did some investigating and discovered that the handles increased anytime the background thread fired an event that updated the GUI thread via invoke. The background thread in my program constantly captures the same data from an external process every few seconds. I have the background thread running in a Do while loop. Is it normal for the handles to increase like that? This is my first project using a continuously operating background thread so I’m a little green at doing this. Here is my code for updating the GUI thread:

Public Sub SetText(ByVal ctrl As Control, ByVal text As String)

       'This sub updates the text to the required control
       If ctrl.InvokeRequired Then
           ctrl.Invoke(New SetTextDelegate(AddressOf SetText), ctrl, text)

       Else
           ctrl.Text = text
       End If

   End Sub

当我跟踪Windows 2000系统上的句柄数时，句柄当我开始这个项目的时候开始时已超过7000，但后来保持稳定。有谁知道为什么任务管理器在2个不同的系统上报告的句柄数量有这么大的差异？他们是否报告相同的事情？



有没有人对导致屏幕重绘速度减慢的原因有任何其他想法？既然我没有在XP系统上遇到问题，那么它可以像为Windows 2000系统添加更多内存一样简单吗？

When I tracked the number of handles on the Windows 2000 system, the handles started out at over 7000 right when I started the program but then stayed very steady. Does anyone know why there is such a big difference in the number of handles reported by task manager on the 2 different systems? Are they reporting the same thing?

Does anyone have any other ideas on what is causing the screen repaint to slow down? Since I’m not having the issue on the XP systems, could it be something as simple as adding more memory to the Windows 2000 systems?

推荐答案

GDI中的漏洞对象不是唯一可能的内存泄漏。而任何其他非托管对象的泄漏并不是唯一可能的内存泄漏。它也可能是一个托管内存泄漏，但这可能是一种不同的泄漏，设计泄漏或一般代码设计中的错误。



请通过一些代码设计建议，查看我过去对该主题的回答：

WPF DataBinding中的内存泄漏 [ ^ ]，
MDI表单中的内存管理 [ ^ ]，
Best摆脱公共静态列表导致出局的方法内存 [ ^ ]，

推迟循环中的变量会导致内存泄漏？ [ ^ ]，

Garbage collectotion负责所有内存管理 [ ^ ]。



现在，一些模式建议：



首先，不信任任务经理，就是不。如果您无法纯粹分析地解决问题，请尝试查找并使用一些真正的内存调试器： http：// en.wikipedia.org/wiki/Memory_debugger [ ^ ]。

我没有使用它们（迄今为止很好:-)），所以我不能特别推荐任何东西，你可能需要自己做出选择，获得一些经验。 br />


最后，您报告同时拥有许多GDI对象和句柄。这可能是应用程序设计不良的标志。所以，我建议你检查你的设计。

-SA

The leak in GDI objects is not the only possible memory leak. And the leak in any other unmanaged object is not the only possible memory leak. It could also be a managed memory leak, but that could be a different kind of leak, leak "by design" or by mistakes in the general code design.

Please see my past answers on the topic with some code design advice:
Memory leak in WPF DataBinding[^],
Memory management in MDI forms[^],
Best way to get rid of a public static List Causing an Out of Memory[^],
deferring varirable inside the loop can cuase memory leak?[^],
Garbage collectotion takes care of all the memory management[^].

Now, some mode advice:

First, don't trust Task Manager, just don't. If you cannot resolve your problem purely analytically, try to find and use some real memory debugger: http://en.wikipedia.org/wiki/Memory_debugger[^].
I did not use any of them (so far so good :-)), so I cannot recommend anything in particular, you may need to make your choice by yourself, get some experience.

Finally, you reported having many GDI objects and handles at the same time. This could be a sign of bad application design. So, I would advise to review your design.

—SA

这篇关于如何在Vb.net winforms中调试慢速屏幕重绘的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！