Memory problem with my VB code.

[Deng Zhang]

Here is my dilemma. I have a subroutine runs every 100mS. At the first, I
found that the system hangs after a few hours when I run this program. I
checked the memory usage under XP Task Manager. I found that memory used by
my program keep growing in a rate of 12KB per second.

Here is what I think the program is doing. The 100mS subroutine could not
complete in 100mS. Then the second comes, then third..... This makes the
stack used by the code keep growing until crashes the system.

I am thinking this is because the code did not get enough CPU time. Is a way
I could increase the priority level of the code within VB so that the system
will assign more CPU time to the process?

BTW, I use VB .NET 2003.

Thanks,

Dave

[Stephany Young]

You don't say so, so I will assume, for the purposes of the argument that
you are using a Timer control with the Interval property set to 100.

The first question you need to ask is:

Is it important that the subroutine runs EVERY 100ms?

If the answer is no, then I would be inclined to stop the Timer control
immediately the subroutine starts and start the Timer immediately befor the
subroutine ends. This will ensure that the problem you describe will not
occur, BUT, it will also mean that the subroutine will run 100ms after it
finishes.

If the answer is yes, then the next question is:

If the subroutine is executing when the Timer 'fires', can it be
'skipped'?

If the answer to this is yes, then setting a flag when the subroutine starts
and setting it when it ends gives you the ability to check to see if the
subroutine should be run. If not, then ignore it this time around.

I hope that gives you some food for thought.
"Deng Zhang" <de********@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

Here is my dilemma. I have a subroutine runs every 100mS. At the first, I
found that the system hangs after a few hours when I run this program. I
checked the memory usage under XP Task Manager. I found that memory used
by my program keep growing in a rate of 12KB per second.

Here is what I think the program is doing. The 100mS subroutine could not
complete in 100mS. Then the second comes, then third..... This makes the
stack used by the code keep growing until crashes the system.

I am thinking this is because the code did not get enough CPU time. Is a
way I could increase the priority level of the code within VB so that the
system will assign more CPU time to the process?

BTW, I use VB .NET 2003.

Thanks,

Dave

[Herfried K. Wagner [MVP]]

"Deng Zhang" <de********@yahoo.com> schrieb:

Here is my dilemma. I have a subroutine runs every 100mS. At the first, I
found that the system hangs after a few hours when I run this program. I
checked the memory usage under XP Task Manager. I found that memory used
by my program keep growing in a rate of 12KB per second.

Here is what I think the program is doing. The 100mS subroutine could not
complete in 100mS. Then the second comes, then third..... This makes the
stack used by the code keep growing until crashes the system.
How do you start the routine every 100 ms? Are you using a timer? Do you
start the instances of the method in separate threads? Are you sure that
all resources are disposed when they are not needed any more?
I am thinking this is because the code did not get enough CPU time. Is a
way I could increase the priority level of the code within VB so that the
system will assign more CPU time to the process?

This may solve the problem for one machine, but there is still no guarantee
that your application will run as expected all the time.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Larry Serflaten]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote

Here is what I think the program is doing. The 100mS subroutine could not
complete in 100mS. Then the second comes, then third..... This makes the
stack used by the code keep growing until crashes the system.

How do you start the routine every 100 ms? Are you using a timer? Do you
start the instances of the method in separate threads? Are you sure that
all resources are disposed when they are not needed any more?

I would suggest that any process that expects to continiously repeat for
the life of the application should have all of its needed objects created prior
to starting the timer. While the GC may be good at disposing short lived
objects, (such as those created and destroyed inside a Tick event) there is
no advantage in requiring it to do so, if it can be avoided.

As you stated, a priority fix might work on one system, but that is not the
going to be the best route to take. Applications are supposed to 'play well'
with other applications so stealing CPU cycles is a bit too presumptious
about what the user really wants to do.

It would be better to clean up the design, rather than grab more resources.
A peek at the actual timer code would help to find other possible suggestions....

LFS
LFS

[M. Posseth]

All ,

Well in the MS cirucular reference example there is still a object=Nothing
line in it and with hanging resource claiming objects ( like database
connections ) it is recomended to implement your own dispose method to
"help" the GC

As nowaday`s a lot of programmers see the GC as a free ticket to write
garbage code that they do not clean up , however the garabage collector is
not so very stipt as one might think before it detects circular references.

So it is always good coding practice to clean up your own mess ( put it in
bags and set it ready to take away with the garbage truck ) by disposing
and setting objects to Nothing so they are marked to take away from memory .

I think that this was more what Herfried was mentioning
If this really was thread related i would say implement a thread lock and
clean up your mess in the lock correct me if i am wrong but i think that
this would also solve the reentry problem

"Larry Serflaten" <se*******@usinternet.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote

Here is what I think the program is doing. The 100mS subroutine could not complete in 100mS. Then the second comes, then third..... This makes the stack used by the code keep growing until crashes the system.
How do you start the routine every 100 ms? Are you using a timer? Do you start the instances of the method in separate threads? Are you sure that all resources are disposed when they are not needed any more?

I would suggest that any process that expects to continiously repeat for
the life of the application should have all of its needed objects created

prior to starting the timer. While the GC may be good at disposing short lived
objects, (such as those created and destroyed inside a Tick event) there is no advantage in requiring it to do so, if it can be avoided.

As you stated, a priority fix might work on one system, but that is not the going to be the best route to take. Applications are supposed to 'play well' with other applications so stealing CPU cycles is a bit too presumptious
about what the user really wants to do.

It would be better to clean up the design, rather than grab more resources. A peek at the actual timer code would help to find other possible suggestions....
LFS
LFS

[Cor Ligthert]

Stephany

I have exactly the same idea

:-)

Cor

[Larry Serflaten]

"M. Posseth" <mi*****@nohausystems.nl> wrote

So it is always good coding practice to clean up your own mess (...)

I think that this was more what Herfried was mentioning

I think so too, but I was just attemtping to say they shouldn't be
making a mess, in the first place! <g>

If they don't create any objects (in the Tick event) then there won't
be any that need disposing.

LFS

[Deng Zhang]

Thanks for everybody's help.

Yes, I was using a control with Interval value set to 100mS. The subroutine
I mentioned is the timer handler. Maybe I should give a brief description
about what the program doing. Program continuously read data from a COM port
(9600-baud rate) and parses the data with the protocol. The data packages
come from a microprocessor and could be any of following: four channels of
A/D, front panel key strokes, rotary encoder actions and life ticks. All
these are graphically displayed on the screen and refresh with the incoming
data. Every thing worked great except that memory problem. I thought that
was a priority issue I tried to change the process priority to High or even
Real Time. There was no any difference.

Today I tried to change the interval value to 250mS and 500mS. I also
changed the Comm port maximum read count from 20 to 200. That seemed fix the
problem. I will try to use the flag on Tuesday. It is for sure that error
will not appear if I set interval greater than 500mS. But the screen
response would be too slow. I am trying to figure out the minimum Interval
value for the program.

Btw, the program is for hardware testing. It will only run on the platform
we designed. It is a 1GHz Intel compatible VIA processor. I did not have any
threading in my program although I can see process has 11 threads under the
task manager.

I did not create any objects. The program is in old C style because I
thought that is the most efficient way for this type of real time display. I
will keep learning from your suggestions.

I do appreciate your response.

Dave

"Larry Serflaten" <se*******@usinternet.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

"M. Posseth" <mi*****@nohausystems.nl> wrote

So it is always good coding practice to clean up your own mess (...)

I think that this was more what Herfried was mentioning

I think so too, but I was just attemtping to say they shouldn't be
making a mess, in the first place! <g>

If they don't create any objects (in the Tick event) then there won't
be any that need disposing.

LFS