How to solve the performance decay of a VB.NET 1.1 application?
I have a single threaded Windows application written using VB.NET and targeting Framework 1.1 . The software communicates with external boards via a serial interface and consists mainly of a state machine that performs some tests, in a timer loop with a 50ms interval.
Feedback to the user interface is done through some custom events that are raised during tests.
The problem that drives me crazy is that performance degrades slightly over time, especially after 1200/1300 test operations. The memory occupied does not increase over time, this problem is of interest only to the processor.
The weird thing is that when targeting the 2.0 framework and using identical code, I don't have this issue.
I know this is difficult without looking at the code, but do you have any suggestions on how I can approach the problem?
EDIT : I am really lost, after a couple of intensive work the app starts to slow down. The selected row is related to her process, if that might help.
EDIT2 : Using Windows Task Manager, I found that the "Handles" counter is incremented by 1 at the end of each operation. I don't know if this is the reason, but the application starts to slow down when the label counter reaches about 1500 labels. I have verified that all required RemoveHandler is called after each operation. Any ideas?
EDIT3 : I found that the pens problem is generated by the C ++ library we are using to communicate with the serial device. This happens in both .NET 1.1 and .NET 2.0. The difference, and strangely enough, is that if in .NET 1.1 the application slows down / freezes instead of .NET 2.0, I get over 30,000 handles without any performance degradation. Now I don't know if the problem is really caused by these lost handles, I will try to ask the C ++ library developers to fix the problem and see if it solves the problem I am having in .NET 1.1.
a source to share
OK, since you cannot use the Performance Profiler, I can think of two things to try.
1) This is a dumb / obvious question. Are you absolutely sure you're firing anything that implements IDispose?
Even if you're sure to go back and check again, watch out for temporary objects that won't be deleted, for example.
string s = objA.GetAThing().ToString()
where GetAThing () returns an object that implements IDispose.
2) Have you tried forcing the trash can?
Read Rico Mariani Performance Tidbits , sometimes not only OK to name GC.Collect()
, sometimes it is necessary.
We have a large rich winforms.Net application that we need to force a collection onto every ten minutes or so. If we don't launch the application after a couple of hours,
Hope it helps :)
UPDATE
It's a shame. Do you have a C ++ source? Or are you stuck with this issue?
If you get stuck, you can periodically start a new instance when the current instance ends.
You can use a locked file or Mutex to ensure that a new instance does not start processing until the first one completes.
a source to share
Full disclosure: I'm on the Visual Studio Profiler team.
Edit: The following is not helpful as VS Profiler doesn't work with .NET 1.1. Have you tried running your code under a profiler? Visual Studio 2005/2008 (Developer Edition / Team Suite) and Visual Studio 2010 Premium / Ultimate have a built-in profiler. There are also third party .NET profilers.
Running the code under the profiler will show you where your CPU is doing the most work. If you're only looking at times when performance is degrading, the results should help you understand why.
Alternatively, you can simulate cheap profiling: debug your application and log into it periodically to see what is running on the call stack.
Also, is your machine installed . .NET Framework 1.1 SP1 installed ? Can you reproduce this problem on other machines?
a source to share
First, I would use the Performance Profiler included with Windows pretty much as Tess suggests here .
Then I would use windbg as she suggested here .
I only suggest windbg because if you haven't used it you should have a small WTF session until you get it (it's still worth getting). Perhaps playing with counters you can find the problem.
a source to share