Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 371
  • Last Modified:

Inconsistant memory usage at startup

I have an WIN32 application made with Delphi 6. It's used about 27 Mb of memory at startup but sometime, the memory usage peak at 60, 100 and even 160 MB in Task Manager. After Initializing, the App create a DataModule, who itself instantiate some customs Classes, and create the MainForm (in full screen). Nothing special worth for posting here anyway i think. It have no specific patern for the memory peak since it happen sometime two time in a row or after four normal memory usage startup. There is no slowdown either (AFAIK) using the app even if it's mem is at 160MB.

Why would a thing like this crappy memory peak happened?

And how did i find wich component used this much memory?
I tried InstanceSize but it look like it didn't return the global size of my object and it would be too long to calculate it for every object i created.

I have tried to delete most object creation and use breakpoint to see where in the code the memory seem to rise but since it happen at random, i really got hard time to reproduced it!

Any suggestion? Third party software who may help? Maybe i look at the problem the wrong way...

Thanks for any clue!
  • 3
  • 2
2 Solutions
It certainly won't be at random. There will be a pattern, even if it is difficult to spot. The DataModule obviously has to interact with a database somewhere, and that can eat memory.

Is this a serious problem? My experience has been that the app will consume the resources it needs as it needs them, and eventually level out. Does it come down from that 160MB peak? Or just keep going up forever? A constant rise would indicate a memory "leak" somewhere - an object/component/resource that's being created (again and again, usually) but never destroyed.
If the usage of more memory only at start up it may not  be a memory leak.
Application is taking the resources to initialize.

To avoid this generally(in case of a no-memory leack)
Don't open all the tables at start up
Create Forms dynamically instead of opening it at startup of the applicaiton
Have a look on this PAQ

Also can try

TELEBECINFOAuthor Commented:
No database is opened at start up and no database at all in the projet (no databinding field of any kind).

"If the usage of more memory only at start up it may not  be a memory leak.
Application is taking the resources to initialize."
So, we can say the ressource taking while initializing vary in my case. Now i need to find the "why"...

When it's peak at 160MB after startup, there is no other memory rise other than normal forms creation as the user use the app.
I take a look at your link but the application quite fast at start up (about 5 second, a bit more if the screen is resize). And it 6.36 MB large (mostly because large image integrated in ressources).

I'll detail a bit more what happening at start up from my dpr :

1- Create DataModule
 [In the datamodule...]
 1.1- Create a thread (TThread) that connect a web site looking for update (Thread is killed after15 sec if no response)
 1.2- Create a custom TComponent class who read a XML file and store the values in different property.
 1.3- Create a custom TComponent class for communication purpose with a DBL system (yeah, old application...)
   1.3.1- Create custom storage classes with array
   1.3.2- Create TStrings object
   1.3.3- Create others custom TComponent class

2- Using EnumDisplaySettings and ChangeDisplaySettings, validate actual screen size and color, changing it as necessary for best supported resolution for 1280x1024, >16 color.

3- Mainform creation
4- Loginform creation
5- Others static form creation (i delete them while i tested but the memory problem still happen)
5- Application.Run

On Mainform FormShow event, it load it background with a  LoadFromResourceName (~3 MB image).
On Mainform FormActivate event, it LoginForm.ShowModal.

On LoginForm.FormShow, it get the users list from a flatfile and display it in a pick list.

Thats it.

I can create LoginForm instead of ShowModal on the MainForm.OnActivate but i don't think the problem is there since i'll just reported the creation a few step later.

I had find memcheck from previous search before posting here but my guess is that it more for finding memory leak. In my case, there is not object destruction yet after start up so it's a leaking issue (unless i mistunderstood what a leak is). Sometime it had the good size, sometime not....

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

TELEBECINFOAuthor Commented:
I forgot a some word in my last sentence :

"I had find memcheck from previous search before posting here but my guess is that it more for finding memory leak. In my case, there is not object destruction after start up so *i think* it's *not* a leaking issue (unless i mistunderstood what a leak is)."
TELEBECINFOAuthor Commented:
Finally, the problem was with a third party component i was using with the thread to know if there was an update available. The component was updated without my acknowledge.

For reference purpose, the component (THttpCli (c) 1997-2005 F. Piette V1.88) is used to connect to a web server, get a MD5 for specific files (calling a php page) and compare it with user's file. The problem occur when calling the hashing php page, on the OnDocData function. The previous code was
FData := FData + String(Buffer)
and with the new version, it now
FData := FData + PChar(Buffer)

I have no idea why it make the memory peak but anyway, my problem is now resolve.


Glad you got it sorted out!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now