Silverfrost Forums

Welcome to our forums

Commit charge in Win2000

28 Jun 2007 7:34 #2004

When we launch our program under Windows 2000 the commit charge memory value goes up by over 1Gb. Then, when a file is opened it goes up a little more and even when the file is closed the memory never gets released. I have monitored this in the 'Processes' window in Windows Task Manager.

Then, even more worryingly when the program is exited the commit charge value only goes down by 800Mb, thus resulting in a 'memory leakage' of over 400Mb. Windows XP seems to have got rid of the memory leakage problem as the commit charge value drops immediately the program is exited.

It has been explained to me by our developers that the huge amount of 'commit' memory is down to the big arrays which are defined when the program is run, but over 1Gb sounds like a lot to me.

Does anyone else have any such experience and is there a purge memory function we should be running?

Thanks in advance.

28 Jun 2007 7:44 #2005

If there is a memory leak after the program exits then this is entirely down to the operating system.

SLINK allows you to vary the amount of memory committed when the program starts up. See the SLINK documentation in the FTN95 help file.

28 Jun 2007 8:11 #2006

OK thanks, but all of the other applications I have tested on the same computer don't generate the same memory leakage when they are exited. I assumed that this was unique to FTN95.

Does anyone know how to purge memory in Win2000?

28 Jun 2007 11:24 #2007

Have you checked the Task Manager to ensure that the program has fully exitted?

28 Jun 2007 11:58 #2008

Yes, completely. No problems with it disappearing off the list and nothing left there which doesn't relate to other applications.

Here are the various screenshots.

First, before the FTN95 application is loaded...

http://www.dtmsoftware.com/Support_files/tech_support/Pre_LSS1.jpghttp://www.dtmsoftware.com/Support_files/tech_support/Pre_LSS2.jpg

Now, after the application is loaded...

http://www.dtmsoftware.com/Support_files/tech_support/With_LSS1.jpghttp://www.dtmsoftware.com/Support_files/tech_support/With_LSS2.jpg

Now, after the application has been closed...

http://www.dtmsoftware.com/Support_files/tech_support/Post_LSS1.jpghttp://www.dtmsoftware.com/Support_files/tech_support/Post_LSS2.jpg

I hope this helps.

Thanks.

28 Jun 2007 1:37 #2009

Nigel,

I develope FEA pre and post processing software, which can generate very large model meshes but can also import very large amounts of geometry information from CAD. I place all my large arrays in common blocks and use the 'virtual common' facility when linking. I find that this method is very efficient in memory handling, and I do not have any problems with large models.

Do your developers make use of 'virtual common' ?

best regards,

John Horspool Roshaz Software Ltd. Gloucestershire

28 Jun 2007 3:42 #2010

Quoted from JohnHorspool

I develope FEA pre and post processing software, which can generate very large model meshes but can also import very large amounts of geometry information from CAD. I place all my large arrays in common blocks and use the 'virtual common' facility when linking. I find that this method is very efficient in memory handling, and I do not have any problems with large models.

Do your developers make use of 'virtual common' ?

Gloucestershire

Thanks for your input John

Your suggestion about 'Virtual Common' could well prove to be of use. We'll look into it. Many thanks for your time. I'll post any findings back here.

28 Jun 2007 3:59 #2011

**Many thanks John

We tried Virtual common and it appears to have solved the problem. Now the Commit Charge memory usage is much lower and when the program quits all of it is relinquished.

A result I think!

Nigel**

28 Jun 2007 8:03 #2012

Nigel,

Very glad to be of help. This forum has been very useful to me in the past, and I'm happy to assist others.

John

Please login to reply.