Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Performance / August 2003

Tip: Looking for answers? Try searching our database.

.NET ver1.1 application taking too much virtual memory

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Sherif ElMetainy - 28 Aug 2003 23:20 GMT
Hello

I had a windows forms application that was originally developed using .NET
1.0, it was running fine but lately i decided to move to .NET 1.1
Now the application takes a lot of memory at startup (about 150 MB) compared
to 20 MB when running on .NET ver 1.0.
And after running for about 15 minutes the computer runs out of virtual
memory (Windows 2000 Pro, SP4, 256MB, .NET ver 1.1, all windows updates
installed) . The code for the application is unchanged between the 2
versions, just recompiled.

Is there a solution for this, or should I just revert to old good version
1.0? Since for me 1.1 caused problems and less performance.

Thanks a lot for reading this and for your help

Best Regards

Sherif
Jon Skeet - 29 Aug 2003 08:03 GMT
> I had a windows forms application that was originally developed using .NET
> 1.0, it was running fine but lately i decided to move to .NET 1.1
[quoted text clipped - 7 lines]
> Is there a solution for this, or should I just revert to old good version
> 1.0? Since for me 1.1 caused problems and less performance.

It sounds like maybe you were relying on unspecified behaviour before,
and it's changed. Have you been able to write an example program which
demonstrates the problem, or used a profiler to try to work out where
the heap is being used?

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Justin Rogers - 29 Aug 2003 13:11 GMT
There are some undiagnosed issues where a machine with a rather large amount
of system memory can cause the GC to heuristics to not kick in in time to
collect and bring the virtual memory back down.  I've worked on a number of
applications that have had the issue of the GC allowing an application to
take up nearly all system memory before actually running a collection.  You
may want to find some opportune places in your code to place GC.Collect(2)
statements and see if that brings your application back to life.

Signature

Justin Rogers
DigiTec Web Consultants, LLC.

> > I had a windows forms application that was originally developed using .NET
> > 1.0, it was running fine but lately i decided to move to .NET 1.1
[quoted text clipped - 12 lines]
> demonstrates the problem, or used a profiler to try to work out where
> the heap is being used?
Sherif ElMetainy - 29 Aug 2003 18:28 GMT
Justin, Jon thanks a lot for replying

I do call GC.Collect() on some place, my application is a race software so I
call GC.Collect() after unloading a race or loading a new race. This was in
the old version as well as in the new version. The problem is also that the
software takes a huge amount of memory at startup, and the system runs out
of virtual memory after 15 minutes, with no other programs running.

Jon was saying that I may be using some unspecified behaviour. I believe
that all methods I call from the .NET class library are documented and I use
them as indicated in MSDN. I also checked the breaking changes in version
1.1, and none of them affects my program.

But one of the assemblies in the application is built using a dll generation
tool that I made using System.Reflection.Emit, originally the dll was
generated using .NET version 1.0, but I recompiled my tool with 1.1 and
generated the assembly again to use 1.1

Although it was not my intention to protect the code in the generated
assembly in any way, but all decompilers that I know of can't decompile my
assembly, because I optimise the IL code in a different way than the C#
compiler, yet I still use well documented IL instructions.

Also, the software is working very good on my development machine, with 1GB
RAM, and it runs for days very good. But I need to make it run on 256MB and
128 MB machines, and it did very good with .NET ver 1.0

Sorry for the long problem description.

And Thanks a lot for your help

Best Regards

Sherif

> There are some undiagnosed issues where a machine with a rather large amount
> of system memory can cause the GC to heuristics to not kick in in time to
[quoted text clipped - 23 lines]
> > demonstrates the problem, or used a profiler to try to work out where
> > the heap is being used?
Jon Skeet - 29 Aug 2003 18:37 GMT
> Jon was saying that I may be using some unspecified behaviour. I believe
> that all methods I call from the .NET class library are documented and I use
> them as indicated in MSDN. I also checked the breaking changes in version
> 1.1, and none of them affects my program.

What I meant was that you may be, say, not disposing something that you
should be disposing of, or something similar.

As I say, a profiler is probably your best bet at the moment, so you
can find out what instances are eating up your memory.

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.