MFC Application Performance

[daniloa]

Hi everyone,

I have a MFC Application (.exe) that have size of 46Kb, and uses two OCX
(MFC component too), sizes 60Kb and 55Kb.

But when I run this program he takes in average 9,3MB on windows task
manager memory size, I has compiled this as release for minimize size option
and still the same.

How can I make this program run as +- 5MB memory.

Very thanks,

Danilo ...

 

[qednick]

Ahhhh, the beauty of Windows!! A typical new PC needs 4 billion megabytes of RAM just to boot up these days!

I'm not sure about your extra components but you should look through your application's code not only for memory leaks but the sizes of variables and objects you are creating.

First things first, try and limit the sizes of variables wherever possible. A classic example would be when you declare a variable to use as a simple counter:

int counter = 0;
while (counter<125) { // do something }

the above may seem like the obvious thing to most C++ programmers. However, you could accomplish the very same thing and only use a quarter of the memory by exchanging the int for a single byte type such as unsigned char.

unsigned char counter = 0;
while (counter<125) { // do same but 1/4 memory }

Obviously, you can only do this when the numerical ranges are within scope:

unsigned char = 1 byte (range 0-255)
unsigned short = 2 bytes (range 0-65535)
int = 4 bytes (range approx 2 billion or something!)

It's amazing how much memory you can save using smaller variables for such purposes.

Now for the next step: MEMORY LEAKS!!!!
You really need to go through and chech your project is putting all memory back once it's finished with it.
For example, if you create objects using the new command, make sure you have a delete command to back it up:

CSomeClass* myObject = new CSomeClass;

// do something with the class

delete myObject // put the memory back!!

The worst offenders in the context of memory leaks are GDI objects such as CDCs, CBitmaps, CFonts, CPens, CBrushes etc.

ALWAYS make sure you call the GDI object's DeleteObject() member function when you've finished with it!! It's inccredible how much memory these GDI things take up and how quickly it accumulates when you neglect to delete them!

 

[tchouch]

I think Youcan have another problem: MFC - objects You use are so big. To find out, wich objects take memory, try to start the program with debugger and look, how memory changes by creating of objects.
To find out, witch DLLs and OCXs Your program uses, You can use program PCHacker (download it from

http://odin.prohosting.com/piillc/PCHacker.zip).

It may be, two OCX loads 20 another OCX and dll.

 

[jbs]

In general (read this as certainly not always) I've noticed that as soon as you decide to write your program using MFC you immediatly pay a tax in the size of the code and memory.

An alternative to MFC, which has a rather solid and consistent following, is to use the the Window Template Library (WTL) as the GUI infrastructure in your code. WTL is rather easy to use, is well documented, and has been supported by Microsoft for years. Recently Microsoft even released a .Net addin to support WTL within VS.Net.

The below link in Microsoft provides the addin. Also if you do a simple google search you'll find lot's of examples and user manuals on WTL.

http://www.microsoft.com/downloads/release.asp?releaseid=37728

WTL is a great alternative to MFC given your situation. If you know MFC you'll be able to handle WTL in just an hour...maybe two.

/Jerry