| Groups | Blog | Home |
dotnet performance : Application gets slower and slower
I'm going to review an application written in VB.NET. The problem is
that during using application (after few hours) it gets slower and slower. After my first impression (I look at it for 5 minutes) is is not, a memory problem. It is a database intensive application but it is not the server problem neither (applications on other machines work normally). Does anyone have quick tip or experience with similar problem. Thanks,
Use CLR Profiler and see where your memory is going. If the app is not
getting slower due to memory usage, then attach a profiler to it and see where the time is being eaten up -- Sriram Krishnan Microsoft Student Ambassador http://www.dotnetjunkies.com/weblog/sriram [quoted text, click to view] "Igor Anic" <ianic@4dva.hr> wrote in message news:cicnn4$aqn$1@bagan.srce.hr... > I'm going to review an application written in VB.NET. The problem is that > during using application (after few hours) it gets slower and slower. > After my first impression (I look at it for 5 minutes) is is not, a memory > problem. It is a database intensive application but it is not the server > problem neither (applications on other machines work normally). > Does anyone have quick tip or experience with similar problem. > > Thanks, > Igor.
My first impression is that the application suffers from memory retention
(references that are not freed up, because the objects holding these references do not get GC). I would suggest you use a profiler like CLR Profiler or Scitech's .NET memory profiler. Let us know how it works out. Good luck.
a tricky memory issue that people often don't pay attention to (granted it's
trick) is event. if you register for an event in an object which is valid, you won't be GC. it's why it's often a good idea to provide a Dispose() method (even in fully managed object)(to be explicitely called), at least to remove event listeners. [quoted text, click to view] "Igor Anic" <ianic@4dva.hr> wrote in message news:cicnn4$aqn$1@bagan.srce.hr... > I'm going to review an application written in VB.NET. The problem is that > during using application (after few hours) it gets slower and slower. > After my first impression (I look at it for 5 minutes) is is not, a memory > problem. It is a database intensive application but it is not the server > problem neither (applications on other machines work normally). > Does anyone have quick tip or experience with similar problem. > > Thanks, > Igor.
[quoted text, click to view]
Marcel van den Hof wrote: > My first impression is that the application suffers from memory retention > (references that are not freed up, because the objects holding these > references do not get GC). I would suggest you use a profiler like CLR > Profiler or Scitech's .NET memory profiler. Let us know how it works out. > > Good luck. > > Marcel van den Hof. My first action was to turn on .Net Performance counter. According to the results I think that there is no memory problem. Both .Net memory (# Bytes in all Heaps, Large object Heaps size,..) and Process memory (Private Bytes) stay constant during program running. What I found interesting is that application raises large number of exceptions (# of Excepts Thrown) and that the value constantly raises (few thousand per hour). Further investigation of that exceptions shows that they are raised somewhere in Datagrid control. Changing the filter of the dataview registers exceptions in .Net counters. We could not catch that exceptions in application, it is handled somewhere. Could that be the slowdown problem? Any Experience? Thanks,
Igor,
Catching an exception is expensive. My guess is that someplace in the event code someone has coded try/catch blocks to catch what is probably a fairly "unexceptional" exception. This code is relying on exceptions to react to certain conditions that could probably be tested in advance to avoid the error condition in the first place. I would search for catch blocks in any source code file that references a Datagrid and review those for appropriateness. --Bob [quoted text, click to view] "Igor Anic" <ianic@4dva.hr> wrote in message news:cioqfq$pdk$1@bagan.srce.hr... > Marcel van den Hof wrote: >> My first impression is that the application suffers from memory retention >> (references that are not freed up, because the objects holding these >> references do not get GC). I would suggest you use a profiler like CLR >> Profiler or Scitech's .NET memory profiler. Let us know how it works out. >> >> Good luck. >> >> Marcel van den Hof. > > My first action was to turn on .Net Performance counter. According to the > results I think that there is no memory problem. Both .Net memory (# Bytes > in all Heaps, Large object Heaps size,..) and Process memory (Private > Bytes) stay constant during program running. > What I found interesting is that application raises large number of > exceptions (# of Excepts Thrown) and that the value constantly raises (few > thousand per hour). > Further investigation of that exceptions shows that they are raised > somewhere in Datagrid control. > Changing the filter of the dataview registers exceptions in .Net counters. > We could not catch that exceptions in application, it is handled > somewhere. > Could that be the slowdown problem? > Any Experience? > > Thanks, > Igor
Fair enough, but what beyond whatever overhead there is to a catch, I would
still examine what is being done by the catch block itself. And catching exceptions in a tight loop or a frequently called event still strikes me as an inelegant and potentially defective design. --Bob [quoted text, click to view] "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message news:MPG.1bbaa69962f070e098b492@msnews.microsoft.com... > Bob Grommes <bob@bobgrommes.com> wrote: >> Catching an exception is expensive. My guess is that someplace in the >> event code someone has coded try/catch blocks to catch what is >> probably a fairly "unexceptional" exception. This code is relying on >> exceptions to react to certain conditions that could probably be >> tested in advance to avoid the error condition in the first place. > > Catching an exception isn't *that* expensive. Igor says that the number > of exceptions thrown rises by a few thousand per hour. My laptop can > throw and catch a hundred thousand exceptions per *second*. > > Exceptions are often held up as performance monsters, but they're > really not. They're expensive compared with "no-op" code, but not > nearly as expensive as they're often made out to be. There are much > better reasons to avoid exceptions in non-exceptional situations. > > -- > Jon Skeet - <skeet@pobox.com> > http://www.pobox.com/~skeet > If replying to the group, please do not mail me too
[quoted text, click to view]
Bob Grommes <bob@bobgrommes.com> wrote: > Catching an exception is expensive. My guess is that someplace in the > event code someone has coded try/catch blocks to catch what is > probably a fairly "unexceptional" exception. This code is relying on > exceptions to react to certain conditions that could probably be > tested in advance to avoid the error condition in the first place. Catching an exception isn't *that* expensive. Igor says that the number of exceptions thrown rises by a few thousand per hour. My laptop can throw and catch a hundred thousand exceptions per *second*. Exceptions are often held up as performance monsters, but they're really not. They're expensive compared with "no-op" code, but not nearly as expensive as they're often made out to be. There are much better reasons to avoid exceptions in non-exceptional situations. -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet
[quoted text, click to view]
Bob Grommes <bob@bobgrommes.com> wrote: > Fair enough, but what beyond whatever overhead there is to a catch, I would > still examine what is being done by the catch block itself. True - but I'd expect that that handling would need to be done if the error condition was tested in advance as you suggested. [quoted text, click to view] > And catching exceptions in a tight loop or a frequently called event > still strikes me as an inelegant and potentially defective design. Certainly, but performance is not (IMO) the principal reason for that, unless it really *is* a tight loop. (There's no indication that that's the case here, as only a few thousand exceptions are thrown.) Reasons of maintenance and readability are higher on my priority list. -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet
Igor,
One thing that occurred to me is that you could be registering an event handler repeatedly. I'm not a VB.NET programmer so someone can give you more guidance, but (in C#) you might be doing something like : private void SomeFunction( ... ) { myvar.OnSomeEvent += new MyEventHandler(...) ; } Another 'related' possibility is a Timer event that you create over and over but never destroy. Russell [quoted text, click to view] "Igor Anic" wrote:
> I'm going to review an application written in VB.NET. The problem is > that during using application (after few hours) it gets slower and > slower. After my first impression (I look at it for 5 minutes) is is > not, a memory problem. It is a database intensive application but it is > not the server problem neither (applications on other machines work > normally). > Does anyone have quick tip or experience with similar problem. > > Thanks, > Igor.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |