I just created a small app for my contacts and it uses a small database with one table and single Windows Form. IN the Vb IDE, all I did was a simple drag and drop from the data sources panel onto the form. I let the ide create the controls, on the form, to interact with the database. Other then the binding navigator, no other controls are used. No menus......nothing.
I compiled and published the project and installed it on my pc and ran it. I was surprised when I looked in task manager and saw that it was consuming 29 megs of ram. That seems really high for an app so small. Especially when VB Express (as big as the app is) was shown as consuming only 18 megs.
Was just curious if there is a way to minimize the ram usage through compiling options or some other method. Greatful for any comments, links and/or suggestions.
Mike
Tiny app consumes lots of RAM
arif_setiawan
So much can be lost in terms of non-specifics.
There was a time in computing when memory meant physical memory and this would be before there were shared libraries or runtime routines.
Enter "virtual memory"... Memory no longer means physical memory. Memory now relates to the number of pages that a process is using. On larger systems there are the pages in memory and the "balance set" which are stored in a paging file. Even the pages stored on disk are counted as memory.
I also agree with SJ. The number of lines of code has next to no correlation with the number of machine cycles consumed.
HuWu
hi,
i noticed the same thing as soon as i started to learn vb, i want you to try something , start your application and look to your program size in the ram then minmize your application to task bar and see the usage again, then maxmze your application and see the ram usage again, you will find your application take much ram to satart when its allready running it doesn't take all this rams
(this is my personal interpretation i hope any one correct me if i'm wrong) .net depend on Garpage collector program that remove objects from memory if its no more wanted by your application the problem of this GC is that its not allways running , and you can't predect when it will run and clean your ram, for sure it will clean your rams as soon as your system need the resources
so after maxmizing your application this is the normal size of your application according to my understanding (again i'm not sure if this is right or wrong) .if you try that with the IDE itself you will get same result it take more rams as soon as it starts
hope this helps
jneubeck
shakalama,
This is a law of physics (energy specific) not a programming mystery and coding is not immune to it. Without going into the theory of potential and kinetic energy, let's just say all that has physical properties require more energy, (or translated into nerdglish), more RAM to begin in motion than it takes to remain in motion.
Just my twist on it,
Adamus Turner
ahmedbenabdallah
Thanks for all the info......much appreciated.
Mike
zeecue
A couple of links on how the .NET garbage collect works and how to write high performance managed apps...
Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework
Garbage Collection—Part 2: Automatic Memory Management in the Microsoft .NET Framework
Garbage Collector Basics and Performance Hints
How to: Use CLR profiler
Writing High-Performance Managed Applications : A Primer
Best regards,
Johan Stenberg
BCullenward88
Wow - a special thanks goes out to all of yas. I didn't anticipate that kind of response. I made the wrong assumption, thinking the amount of code had alot to do with the amount of ram useage.
I also got waaaay more info than I bargained for. Thanks for the input and for the links.
Cheers,
Mike
daisy1225
Henrik Viklund
This paradigm is conducted on the OS level not the Application level. The OS handles RAM requirements based on the status of the program. If the program is minimized (or idle), the OS recognizes this change and compensates by allocating just enough RAM for the minimized (or idle) application to sustain itself. This smart monitoring activity enables multiple applications to use and share the maximum available RAM. Otherwise, we'd end up with one application hogging all the resources.
Also, VB and the related species are well known for their greedy system resource requests. Unless you rewrite the libraries in your application, your application will quickly contain a lot of unnecesary references, in turn, requiring a substantial amount of hard drive space. (Fortunately, the gamers have pushed the hardware manufacturers to the point of producing almost unimaginable storage devices and memory modules, but this is not a scape goat to discard good programming practices.)
VB.net, from what I've read so far, has incorporated Garbage Collection on some level. (I haven't had time to test it's caliber as of yet) In any event, memory leaks and other such accidental inaccuracies will always be an unavoidable evil that we'll have to deal with regardless of the technology.
My closing top 5 suggestions
1. Think on the scope of your code during design mode not maintenance. (Practice and Preach the SDLC)
2. Don't use global or public variables.
3. Set all objects to Nothing when they are no longer needed.
4. Don't use any IDE's built-in controls if you're not familiar with their hardware/software paradigms
5. Follow those who seek the truth. Doubt those who find it.
Just my twist on it,
Adamus Turner
Karim Hemani
I'll also add, that the amount of actual code required for any given application has not decreased, just because it takes you one line of VB code to open a database, for example.
I remember being shocked, initially, about the memory consumption. But remember what your objectives are and meet them. If it takes 30 (or 100) megabytes of memory, then so be it. If memory consumption is paramount, then the .NET framework is the wrong environment to be programming.
Following the Energy principles mentioned: you don't get something for nothing
.
Jeremy Morton
Remember Mike,
RAM requests from any app will change with the programmed task. It's important to note that your focus on task manager may have been when the application was communicating with the database. During this period, you're witnessing peak RAM requests which isn't extraordinary for open .dbo connections.
To reduce the peak during this time frame when your app requires more RAM for this activity, make sure your queries to the database are refined to only the fields/tables you need to complete the task. For example...if you use "Select * from Members, " the execution plan will ask the OS for a lot more hardware than it really needs. By simply changing this to "Select FName, LName from Members," you've dramactically decreased your RAM requirements.
Also, consider the life span of your database connection. Always kill it asap.
Just my twist on it,
Adamus Turner